The problem I am encountering a great number of imported files. I am trying to slowly inject webpack into a legacy site. There are many global stylesheets:
require('../../../Content/Ones/_forms.scss');
require('../../../Content/Ones/_grid.scss');
require('../../../Content/Ones/_panels.scss');
require('../../../Content/Ones/one.scss');
require('../../../Content/Ones/_grid_tools.scss');
Is there a way to avoid this? I might be just looking at this from the wrong angle because I can't seem to find a question that matches my use case.
Please advise, Thanks!
The SASS files you import (whether you import them from a JS file or another SASS file) are part of your webpack dependency tree, so they should all be watched automatically. If they're not, would you mind adding some more info to your question about your app structure and webpack config?
As for reducing the number of global SASS imports, there are a few ways to do that, but making a good choice here really depends on how your app is structured.
Side question: Is there a reason you're adding webpack to this site? Anything in particular you're hoping to gain? I ask because if it's not a component-based SPA, you might not be getting very much out of webpack, and it may not be worth the trouble.
Related
I have a small (and maybe dumb) question. I am working on my final year project and I was wondering if I can use bootsrap and tailwind css together. I know that they can be used together, I am not asking how to, I am asking if its bad practice or if it will impact the application in a bad way (maybe slowing it down since the app.css is twice as long). I have worked with both of them in the past and I would like to use tailwind on some pages and bootsrap on others. Any advice on this will be appreciated.
Thanks.
As a general rule, it is better not to use too much css in a page for both reasons you mentioned: speed and compatibility.
If you are sure about the compatibility, then it leaves the speed issue.
It is all about a compromise between optimization and ease of implementation which is very subjective.
Since Laravel 5.4, the default method to compile assets is using Laravel Mix, instead of elixir.
I know that "Mix" uses WebPack by default to compile the assets.
What benefits does this method bring?
The Mix also allows you to compile without WebPack, and this always
produces files that are smaller in size and work the same.
This is entirely incorrect. Have you attempted to configure any of the myriad options to optimize your bundle at all?
Start with the webpack-bundle-analyzer plugin. This will give you an idea where your bloat is, what is duplicated, and where to start trimming your application.
Between uglifying, chunking, deduplification, minification, etc. you'll have in the end compiled resources that are far from "large".
Now I'll grant you it has a steep learning curve comparative to other tools, regardless, WebPack is an incredibly powerful tool, you need to take the time to learn it's configuration capabilities.
Care to elaborate on what you mean by working the same? I run several production applications as well as a number of smaller personal projects. I never seem to get different results after each build.
But in the end it's just a tool. A tool like any other tool, you use what you feel comfortable with and what fits for the job. There's a reason it as selected as the default, though. And it isn't because the maintainers are ignorant by any means.
I'm fairly new to Vue and only learn a little bit of it. Actually it's my first time seeing this beautiful library (whatever you may call it ) And i saw many developers actually pulling many dependencies from npm like vueify, and many more. Now, I just want to ask. I'm only a beginner. and what i know is to just pull of my files and store them in my resources/assets/js folder and just do elixir on them. And, is it really a good practice to just pull of those dependencies and browserify/webpack on them regardless the size of the app i'm developing ? Humbly asking for opinions
JavaScript newbie here. I'm new to Angular2 and am currently learning about things like module-loaders (there's so many!), etc, so bear with me since my space of "unknown unknowns" is probably quite large.
I'm interested in creating a JavaScript based "Packaged Web App" for windows ("Packaged" in the sense that the JS is included in the Universal Windows Platform app).
One constraint to keep in mind is that I have severe limitations on the size of my packaged app. The smaller, the better.
With that in mind, I have a few specific questions that will hopefully expose the extent of my ignorance:
Without resorting to Electron or Ionic2, is it possible (also, is it a good idea) to create the offline experience in Angular2 and then only manually include the resulting transpiled .js files in my Visual Studio project?
How hard is it to manage the dependencies for these transpiled files? Are they entirely self contained?
Roughly how large would the minimum set of manually imported files end up being? When I use NPM to install angular2, it winds up being ~80mb - a large portion of this (most?) looks like dev tools, test infrastructure, etc. What's the minimal set of angular dependencies needed for the client app to work?
Thanks!
Without resorting to Electron or Ionic2, is it possible (also, is it a good idea) to create the offline experience in Angular2 and then only manually include the resulting transpiled .js files in my Visual Studio project?
Yes, it is possible. TypeScript will be compiled to javascript codes, which will be consumed by your project. So eventually, it is compiled js codes that will be necessary for your project.
But, if you are so worried about your project's size, then I suggest you using Angular 1, which is only JS codes. And for the minimum size of Angular 1 and its dependency jquery. There is a compressed version of Angular 1 (angular.min.js: 164kb) and jquery(jquery-3.1.1.min.js: 85kb).
Answering my own question here:
Yes, it's possible. You can copy over the transpiled .js files and then simply point the webview control at the generated index.html. With that being said, it's a pretty kludgy dev experience since you're constantly working around VS.
The dependencies are handled for you - it's all in the minified/uglified js files.
I haven't investigated tree-shaking yet, but it looks like I can get away with ~0.5Mb with a skeleton project.
Is there a way to debug a bundled javascript in WebStorm setting breakpoints in the files that are source for bundling, instead of the bundle itself?
I use browserify as bundling package, but I can consider using other ones. The only limitation is that I use grunt as a task runner. Seems there is something that could be a solution here, but it us for gulp. There mentioned vinyl-source-stream as a part of the solution, but I am not sure if it is worth trying with grunt.
What I tried is
using browserify: { options: { debug: true; } }
using mold-source-map and some other related things found here on SO
using uglify as source map generator
some other things that are not worth mentioning
Any one- or two-step things I tried just did not work.
Seems it is too sophisticated to search the way consciously, only try-and-error would work, but I don't have enough time for it.
What I hope to find is a working example of the web storm project where I can set a breakpoint in source js before debugging. But any hint or direction would be appreciated.
Well, if nobody helps me and I find the solution later, I'll surely blog it out as step-by-step instruction. But I am not sure that this is possible due to people who understand more than me in browser debugging told that source map cannot be generated so as to point to the files other that actually executing in browser js engine. So the answer with more detailed explanation why it is not possible can also be accepted.