The online NPM documentation does not explain how to upgrade ember-cli-babel. I tried following the accepted answer posted here Invalid Version: Ember-Cli-Babel, but that did not work.
DEPRECATION: ember-cli-babel 5.x has been deprecated. Please upgrade
to at least ember-cli-babel 6.6. Version 5.2.8 located: library-ui ->
ember-clean-tmp -> ember-cli-babel
Update
I have uninstalled the Ember-clean-tmp add-on. When I run Ember-cli-update I get a message that says Tags match, nothing to apply. I then ran Ember S and get the following warnings:
WARNING: ember-basic-dropdown attempted to include external babel
helpers to make your build size smaller, but your root app's
ember-cli-babel version is not high enough. Please update
ember-cli-babel to v7.3.0-beta.1 or later.
WARNING: ember-power-select attempted to include external babel
helpers to make your build size smaller, but your root app's
ember-cli-babel version is not high enough. Please update
ember-cli-babel to v7.3.0-beta.1 or later.
WARNING: ember-data attempted to include external babel helpers to
make your build size smaller, but your root app's ember-cli-babel
version is not high enough. Please update ember-cli-babel to
v7.3.0-beta.1 or later.
WARNING: ember-basic-dropdown attempted to include external babel
helpers to make your build size smaller, but your root app's
ember-cli-babel version is not high enough. Please update
ember-cli-babel to v7.3.0-beta.1 or later.
WARNING: ember-text-measurer attempted to include external babel
helpers to make your build size smaller, but your root app's
ember-cli-babel version is not high enough. Please update
ember-cli-babel to v7.3.0-beta.1 or later.
WARNING: ember-power-select attempted to include external babel
helpers to make your build size smaller, but your root app's
ember-cli-babel version is not high enough. Please update
ember-cli-babel to v7.3.0-beta.1 or later.
Update 2
I was able to fix the issue by uninstalling ember-cli-babel and re-installing it, which got me to version 7.5.0. But, is this the correct way to upgrade packages?
The problem that you are experiencing is related to one of your addon's depending on an older version of ember-cli-babel.
From the deprecation notice, it's ember-clean-tmp, which doesn't look to be up to date. You have a number of options here. First, you could stop using the addon (which in this case doesn't really seem like a necessary addon. Needing to clear my tmp has never been a problem for me in my 2.18 app).
Secondly, if you'd like to keep using the addon, you could go through the process of upgrading the addon's ember-cli version to a version that includes a high enough ember-cli-babel version. Basically, each ember-cli version has a default blueprint for what dependencies a new app should include. When you ugprade, you diff your dependencies and various files against the default for that ember-cli version. ember-cli-update is an addon that makes this process nice. You can then point at your own fork or better yet, get your update merged upstream in ember-clean-tmp
Open you Command Prompt and type ember install ember-cli-babel and press enter. If you have already installed, don't worry. This will over write.
Reference: https://www.npmjs.com/package/ember-cli-babel
First,
npm install ember-svg-jar
Second,
ember install ember-svg-jar
All I had to do were these commands.
Related
I have a Gatsby starter (taylorbryant/gatsby-starter-tailwind) that uses gatsby-plugin-postcss which is not compatible with the version of gatsby installed in my machine like a few other plugins used in the starter. You can see the warning I get when trying to build for production.
warn Plugin gatsby-plugin-postcss is not compatible with your gatsby version 3.14.2 - It requires gatsby#^2.0.0
How can I downgrade Gatsby to a specific version, maybe just locally?
This isn't too difficult.
Open your package.json file and change the actual version you want to use.
Then run npm update to make sure you update all the packages to the right version.
Please correct me if I'm wrong but I believe that is the way to change the Gatsby version.
Please do keep in mind that this is most probably cause a bunch of other discrepancies with other packages that actually require a higher version in order to work.
You can find more information about how different versions work here: https://www.gatsbyjs.com/docs/reference/release-notes/migrating-from-v2-to-v3/
Best of luck!
I want to look at upgrading NPM on a project I'm working on from 5.8.0 to the latest version.
Is this something that is safe to do without breaking any packages i have installed? And if there's a chance it might, what is the best method for testing those packages to make sure everything is running correctly still?
Updating NPM is unlikely to break anything. However your packages may require a certain version of Node.js to function properly.
There also isn't really a "best method" to check if everything runs correctly. Ill refer you to this answer which has a few options you can try.
We have a private nexus repository and publishing all the npm modules there. We have Module A and Module B, B is dependent on A. Here I am getting an issue with installing the latest SNAPSHOT version. For example:
Module A has published versions like
'1.0.0-SNAPSHOT', '1.0.1-SNAPSHOT', and '1.0.0'
In Module B package.json, I added the dependency like
"Module A": "^1.0.0-SNAPSHOT"
As I mentioned "^" in the dependency, it should install the latest version (i.e, 1.0.1-SNAPSHOT), But I am not sure why it is installing '1.0.0' instead '1.0.1-SNAPSHOT.
Your help would be greatly appreciated. Thanks in Advance.
Avoid releasing and using snapshot dependencies. When you publish a release, it should not contain -SNAPSHOT. Referring to a proper release is mandatory in order to be sure you are testing/executing the right code without side effects due to regression problems. You need to know in every moment which version you are using, that is very important, so relying on latest versions of your modules might not be the best solution, it doesn't worth it either if you are precise with major, minor and patch bits in order to avoid breaking changes or unexpected behaviors.
If you really need to develop them together you can use npm link command instead.
We're using NodeJS for some projects and are faced with an issue that must have a simple solution (seeing as nobody else seems to have the problem).
In the packages.json there are a bunch of dependencies mentioned with a minimum version, each of which may have overlapping dependencies of their own. The default way a dependency is added is using the ^ operator which seems to mean 'compatible with' or 'same major version, but minor versions may differ'.
The way I understand npm to work is on npm install to take the highest minor version available that matches. Unfortunately 'compatible with' is not quite as enforced as you'd hope.
The situation this puts us in is that for instance on a developer machine version 1.1.0 is installed, but between development and publishing a new version 1.2.0, that has a bug, is introduced. On our build machine a fresh build is made which ends up using 1.2.0 and we've introduced a bug that wasn't there in development.
We tried changing the ^ operator to = for instance, but this gives us trouble when dependencies have subdependencies that aren't compatible with the requested version.
All in all I'm a bit confused, but this thing keeps biting us anytime something changes since the development machines don't do anything on npm install if the package is already there, but the build machine always gets fresh copies.
I know from NuGet that it always takes the lowest version that matches all combined requirements. Since this is always the same for a given set of dependencies, I much prefer this approach. Is there a way to make npm work like this too?
To answer my own question:
npm has introduced a new command npm ci which does something similar to npm install but enforces that the specific versions are used that were also used when a package was initially added by using the package-lock file.
See https://docs.npmjs.com/cli/ci for more information
Today I found that an npm package version, Babel 6.0.15, that my application relies on had been removed from npm.
This caused compilation failure on a new pc, and I had to go manually find the closest available version for it, and all the cascading version changes it affected on related packages.
What is the best of way of dealing with npm packages, now that I know they can go missing at any time?
Do you check your node_modules folder into source control?
Is there a rule on npm about what versions (major, minor, etc) may be removed by the creator, and which are more 'long term support' and must be retained?
How do you get npm locally to inform you when 'npm update' fails on a new pc, rather than silently failing?
After thinking about this for a while I wrote a blog post summarising what I think is best practice. Reproduced below:
Summary
Specify exact versions of all npm modules, e.g. “alt”: “0.17.8”
Commit your node_modules folder into source control
Don’t use DefinitelyTyped or any other external library Typescript definition tools
Why?
Some of these principles might be controversial, so here’s my reasoning:
Specify exact versions of all npm modules
Semver (semantic versioning) says that breaking changes should occur only if the major version changes. So you should be able to say just “alt”: “0.17”
But I’ve found in practice that even patch changes (bugfixes) can break your application – because libraries that rely on these library often expect some tiny behaviour in a particular version not to change. So in order for all your particular versions of particular libraries to work, they need to rely on exact versions of other libraries.
Commit your node_modules folder into source control
I first assumed that all versions of famous npm libraries would remain there indefinitely. But I then discovered that creators often remove old versions of their software from npm – which then breaks the cascading chain of exact version number dependencies you’ve configured for your app.
Yes, committing all your npm libraries will take up space in your repository, but they’re text files after all, not .DLLs, so they’ll get compressed really small. And the alternative is one day not being able to compile your app at all on a new computer because a library has been completely removed from npm.
Don’t use DefinitelyTyped or any other external library Typescript definition tools
It’s wonderful to be given compile errors for external tools you use. But I’ve found it’s not worth the effort because:
there’s no way to match the definition file version number and npm library version number, so you get definitions that are out of sync with the library you are using
they often have bugs
the type bugs you catch at compile time are probably going to occur in your own app, not in how you call external libraries
Instead of using .d.ts files for external libraries, just say:
declare module 'lodash'
{
let x: any;
export = x;
}
Or use the –allowJS flag in Typescript 1.8 onwards.