I'm building an application with vue-cli and I see that webpack config is not explicitly defined in my repo. It's hidden from us (although it can be changed). Default run dev script by vue-cli also use vue-cli-service instead of webpack.
I'm a questionning myself about the consequence of this.
Are we losing control over the webpack config?
Does new version could modify the base hidden config without us knowing it ?
Are vue-cli taking too much space and break some decoupling principle (since it will be more difficult to change from webpack to another bundler for example) ?
Thanks in advance.
Regards
(English not my primary language, sorry)
No modern framework's CLI (including Vue) is going to operate not according to best practices.
You can read on how to work with Webpack in Vue here: Link.
New versions with breaking changes are documented like so: Link.
An application built on any framework will depend on that framework, regardless of CLI use. Configurations built from the CLI can always be changed manually.
Related
I have noticed theese two methods for generating a new vue project:
npm init vue#latest
and
vue create <projectName>
Both seem to do the job, but very differently, they boundle very different packages.
Even tho you ovbiously modify the project to your liking, is ther a better start for my project requirements?.
The project i'm talking about, is going to be a single page web application using typescypt, ESlint and tailwind.
Also I have seen that the two methods do not just install unrelated software from one to the other, for example state management is handled by different libraries, and if I am not wrong Vite is the equivalent to Babel.
I am just starting with Vue, and frontend in general (tho i have used Angular), I am more prominently a backend dev, so i am not used to most of the software used here, and I do not really know what they are used for....
To ease finding the solution for others, as commented by Estus Flask, The oficially recomended by the vue devs currently is
npm init vue#latest.
This will set up a project using Vite and Rollup, wich is the currently recomended stack.
The other method is a deprecated one. as it gives you the old stack recomendation, Vue CLI and Webpack, this other stack is currently not enforced by vue devs.
It seems a strict CSP for style-src will be unhappy when webpack's style-loader tries to append inline CSS in a create-react-app (CRA):
I was wondering if I need to use a webpack dev server to take advantage of using a nonce token, or if CRA had a way of circumventing this style issue during development. The REACT_APP_INLINE_RUNTIME_CHUNK=false value doesn't seem to help in this case (in fact, I'm not seeing a difference in the resources that come over the wire between setting it to true vs. false). But I am running npm start instead of npm build, I think the latter properly builds with environmental variables, not sure about the CRA dev server.
From what I can tell, CRA doesn't really want you overriding things. But if you must, you can use something like react-app-rewired, or eject (which is strongly advised against because it will derail package updates CRA uses to keep everything nice and neat and working).
There's also modifying the build files themselves in node_modules/react-scripts/config/webpack.config.prod.js, although what I'm currently doing is commenting-out the meta tag during development and uncommenting on submit, which is about the same amount of work I think if I have to rebuild/reinstall on updating the module anyway. Although I don't typically update it that often.
Source: https://stackoverflow.com/a/64361307/1580355
Recently, node package manager is very popular and doing a lot of job for us, however it is really difficult to understand what is going on under the hood. I really like simple tags to insert Vue, Babel etc. Haven't worked on big projects, I really wonder is there any disadvantages using script tags over npm-cli.
When you npm install a library, plugin, extension, etc it can be declared as a dependency with a --save flag. In doing so it is marked as a dependency in your package.json file, which is key to version control for your dependencies. If you just use the CDN you are pulling in a path to a library that may be deprecated at some point in the future.
During development it is ok to use CDNs, but in production it is not good practice for dependencies (though I do it for certain exceptions, such as a google font).
I am installing vue.js by CLI, and there i have found the command such as
vue init template-name project-name
Thus, I want to know that what are these templates and how many of these are there which will be appropriate for me?
Well, i looked up and researched and found that there are, different versions for templates in Vue, if you are using it by Cli.
Templates are such as:-
webpack
webpack-simple
pwa
simple
browserify
browserify-simple
in which webpack is used mostly. since it provides some css extraction and more features too
Generally developers who are new to any framework, mainly use webpack-simple that sets up all things for them regarding gulp, eslintrc and much more files.
I've been developing in Aurelia-CLI for about 3 months and like it so far. I think it's a solid framework and obviously escalating in support and usage. That's a good thing!
Before I develop much more of my large app, I'm wondering if I'm using the best build system. I've only tried Aurelia-CLI and am not really familiar with Webpack or JSPM, and therefore I don't know what I'm missing. Are there any clear advantages or disadvantages in using either of the other two build systems, or is using the CLI the most clean and supported approach? Since I'm developing independently, I don't have any external constraints.
Thanks for your help.
UPDATE
This answer is almost two years old. Feel free to research updates and provide another more complete answer and I can replace this answer or point to that answer. Thanks!
Aurelia CLI
Aurelia CLI is great for getting started. It's important to understand that under the covers the CLI is using require.js but proxies the configuration through aurelia.json in your application. This means that you need to understand how to configure aurelia to work with require.js at the moment. Once you need to start configuring to match your workflow or change build steps up it gets a bit cumbersome at the moment. We are working to improve this. There are many features planned for the Aurelia CLI but given at the time of writing this that it is in an alpha / beta state it should generally be used on proof of concept or other smaller apps, not production-ready large scale apps yet.
WebPack
WebPack is arguably the most popular kid on the block at the moment. WebPack is not a module loader, but a bundler. It's important to understand this because while we strive to make Aurelia work great with all module loaders WebPack by default is not in charge of loading modules so a dynamically loaded application requires the developer to expand on this. WebPack is strong in creating optimized bundles and can be easy to use as long as you are comfortable with configure WebPack. WebPack has considerably more GitHub stars due to the popularity from React using WebPack it's hard to say whether the choice is better when using Aurelia simply because of the number of GitHub stars.
JSPM / System.js
Some of the skeletons use JSPM and System.js. The reason is that these are the closest to 'spec compliant' solutions. JSPM tries to help as much as possible when loading from the JSPM registry. If not yet available in the registry you can load from NPM or GitHub directly. From a module loading perspective you use a config.js file that is (usually) automatically maintained when installing dependencies to improve the developer workflow.
Side biased note
On most larger apps at the moment I typically prefer using JSPM / System.js simply because I have a great understanding of the tooling and prefer the control that I am provided. I work on a great number of Aurelia apps that are in production and typically reserve CLI for smaller proof of concept apps and WebPack is a great alternative but I prefer the flexibility and understanding I have with JSPM / System.js at the moment.
The CLI isn't currently feature complete, but it is a much simpler setup. Webpack can basically do anything you want to do, but you'll be maintaining your webpack configuration just as much as you maintain your Aurelia code.
Ok, maybe not just as much, but you'll have to learn Webpack to use webpack. The Aurelia CLI is simple to get started, but has some definite limitations. For example, CSS files that reference external resources won't work w/the Aurelia CLI, but they should work fine with Webpack.
First, I can understand if this post gets shutdown due to its subjective nature.
I believe it's time to re-visit the answers about Aurelia CLI being a second-class tool. I respect both PW Kad and Ashley Grant immensely, but I am just not convinced that a statement like this is true anymore:
There are many features planned for the Aurelia CLI but given at the
time of writing this that it is in an alpha / beta state it should
generally be used on proof of concept or other smaller apps, not
production-ready large scale apps yet.
Notably, I have a production application that way back in the day I started with Aurelia CLI, and changed it to JSPM precisely for the reasons noted. But recently, I rebuilt the same app from scratch using the CLI and I realize that it is much easier to use, particularly managing modules and publishing! And this is an app with Google Maps, Google Analytics, Auth0, DevExpress, Bootstrap, etc.
Just think it is time to give Aurelia CLI a little love. It's ready.
Aurelia CLI is the most preferred option with this announcement.
http://aurelia.io/blog/2017/08/18/aurelia-cli-webpack-update/
Now It has more flexibility for your choice of preferences.