I am using the following and want to know what is the best practice to update them? Can I change one, #vue/cli-plugin-unit-jest for example, and the rest update too?
#types/jest": "^24.0.19"
#vue/cli-service": "~4.5.0",
#vue/test-utils": "^1.0.3````
You'd have to upgrade the dependencies all individually and ensure you're using versions that are compatible with one another. However, vue-cli is being replaced by create-vue so if you're planning to upgrade your app you may want to follow the migration guide created by the Vue devs and go with their recommendations.
Here's the guide
And here's what the Vue.js team is currently saying about vue-cli
Vue CLI is the official webpack-based toolchain for Vue. It is now in maintenance mode and we recommend starting new projects with Vite unless you rely on specific webpack-only features. Vite will provide superior developer experience in most cases.
Related
I'm maintaining a library (MyLib) published on npm that is a vuejs plugin. When I started this library, vuejs was at major version 2.x.x. vuejs now has a new major version 3.x.x that changed how plugins work.
Both 2.x.x and 3.x.x versions of vuejs are supported and will be for a while longer. I want my plugin library (currently version 5.x.x) to be available and supported for both.
Options I've seen or considered so far:
Have 5.x.x as the last version that supports vuejs#2 and 6.x.x and above for vuejs#3.
Easy enough
Doesn't allow me to release a new version with breaking changes that supports vuejs#2 ever if I follow semver rules.
Create a version 6.x.x of my library that supports both versions of vuejs.
Potentially possible, depending on the specifics.
Makes my library bloated because it needs to support both versions of vuejs and have (flaky) runtime version detection to choose the right code path.
Publish a separate library (e.g. MyLib-v2) that supports vuejs#3. Can possibly use a scoped package, but that would force users of 5.x.x of my library to change their dependency name with very poor discoverability.
Not sure how to manage this in a single repo. Monorepo?
Clunky, higher overhead
Is there a better way, or at least a not-awful way of managing publishing my library in this seemingly common scenario?
Use vue-demi. It lets you publish for both vue2 and vue3 in the same project. When using vue2, you have will access to the composition api as well.
https://github.com/vueuse/vue-demi
From the read me:
Vue Demi (half in French) is a developing utility
allows you to write Universal Vue Libraries for Vue 2 & 3
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.
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.
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.
What is the best testing framework and its associated helper libraries to use for a project in React and JSPM? I'm looking for various libraries combined together and what is specific to that set which makes it a powerful toolset? (Looking to incorporate redux later on)
I recently build testing environment for a react application using JSPM.
I first wanted to use Jest, as it is recommended by the community with react. But then I found out that thread, saying support for JSPM/SystemJs wasn't on the roadmap at the moment.
Although it exists some work to make it work, see for example: https://www.npmjs.com/package/systemjs-jest
Then I chose to use Jasmine as it is quite known in my company, and I already worked with it.
Also I think Jest used to be based on Jasmine, so many react-specific matchers developed for Jest are also compatible with Jasmine.
So I ended up using Jasmine with Karma, using karma-jasmine and karma-uiuxengineering-jspm.
Make sure to read the documentation of karma-uiuxengineering-jspm thoroughly, it took me some time to set the environment up.
Some nice additions:
- jasmine-enzyme (installed with JSPM)
- karma-mocha-reporter (installed with npm)
- karma-phantomjs-launcher (installed with npm)