I have seen projects with one or both of them and both files contain dependencies and project info. What is the difference and are both valid with version 0.19.0?
elm-package.json is the package manifest used in 0.18. elm.json is the package manifest used in 0.19. It mostly serves the same purpose but uses a different schema that amongst other changes now separates direct from indirect dependencies.
Some more information is available in/via the 0.19 upgrade guide
Related
I have a monorepo (Nx Workspace) that has many libraries that were generated with #nrwl/js. These libraries depend on each other. They are small utility libraries that I intend to publish on NPM as separate packages.
According to Nx docs:
#nrwl/js is particularly useful if you want to
Create framework agnostic, just plain TypeScript libraries within an existing Nx workspace (say to use in your React, Node or Angular app)
Publish TypeScript packages to NPM
Yet, I now realize that the build command associated with #nrwl/js does not take into account a library's dependencies on other libraries in order to include them as peerDependencies into its publishable package.json. It also looks like it is making just a simple commonjs build that would be compatible with node.js but not with browsers.
I know that #nrwl/angular takes care of all that stuff for you when you build a library with it if you had marked it as publishable. My question is how do I get the same behavior but for a library that is not meant for Angular but for general purpose Javascript use in any framework or environment.
It's still early in development so if a solution to my problem would involve regenerating the libs using some other Nx generator, it wouldn't be too much of a hassle for me to do so, and I'd consider it.
Edit
I have since changed the build executor to #nrwl/node, which has the buildable and publishable options and behave the way I need.
I believe that #nrwl/js will eventually gain that ability but as of 2022-01-05 it didn't have it. For now, someone looking to publish libraries on NPM probably should use #nrwl/node to generate his new library projects and not #nrwl/js
If you want to publish a NPM package as a "universal package" to be consumed by Node.js and the browser, you would need to build it as UMD, to cover most consumer environments.
Though modern browsers support ES modules (import and export), you might need extra setup steps to consume them.
I've been asked to upgrade a project to use webpack version 4, and I need to upgrade various loaders and so on to the compatible versions.
So far it's been laborious and slow, and I don't know if I'm getting closer to a solution or not.
As I mentioned in the question, I upgraded webpack to version 4.46.0 but now of course need to upgrade webpack-cli (as well as many other libraries). I want to find the highest version of webpack-cli that's compatible with webpack#4.46.0. After some trial and error, I found that webpack-cli#3.3.12 seems to be the correct version (and not webpack-cli#4.x).
But then of course there are modules that depend on other modules (and so on), which makes figuring out the right versions especially hard.
Are there any automated tools to help with this process?
Unfortunately, no silver bullet! There is no direct automated way to do that. In general, you have to go through documentation of each Webpack loader and plugin and find appropriate version.
There are few guidelines that can help you:
Loaders - Latest versions of Webpack loaders should work any version of Webpack from version 2 onward.
Plugins - Webpack plugins usually cause breaking changes across version. That's where you must test extensively.
CLI - Webpack CLI and Webpack are quite independent from one another. In theory, not too much breaking changes. Webpack CLI is literally a small wrapper around Webpack and thus, you can start from the topmost version and then go backwards.
Certain loaders have dependency on other modules which has a strict requirement set. For example. Babel loader has a strict dependency on Babel (babel-loader 8 needs babel 7.x) and same for sass-loader. You must strictly follow those dependencies carefully.
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.
I've created a new project by checking the "include kotlin" box in Android Studio 3 and out of the box I get an error while compiling
"Failed to resolve: org.jetbrains.kotlin:kotlin-stdlib-jre7..."
I have made sure all plugins are up to date and that the Android SDK is properly installed.
How can I solve for this error?
kotlin-stdlib-jre[7/8] was deprecated a while ago, and has since been removed. The deprecation note was kept until 1.2.71, which was the last version to release those artifacts. The official deprecation notice can be found here. Using any of the deprecated versions (before it was removed) should also produce a warning in (at least) Android Studio and IntelliJ.
Use kotlin-stdlib-jdk7 instead. It's the same dependency as kotlin-stdlib-jre7 (except newer), but it was re-named to kotlin-stdlib-jdk. kotlin-stdlib-jre is now no longer maintained as a separate dependency.
Both IntelliJ and Android Studio currently generate new projects using kotlin-stdlib-jre7; this likely is a bug. They have probably not updated the project generators. Therefore, you have to manually replace the dependencies with working ones until they fix this. This is dependent on the Kotlin plugin. Update it if you haven't. I haven't checked whether it's been patched or not - if it has, that only fixes the creation of new projects. For updating from older versions, the rest of the answer still applies
You naturally have to do this if you're on 1.2.71 or lower, and you're upgrading to 1.3.0 or higher.
These are the new valid dependencies as of Kotlin 1.3.0:
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
Where $kotlinVersion is either a variable containing the version, or a hard-coded version (i.e. 1.3.0)
Alternatively, you can use the "plain" stdlib (kotlin-stdlib) instead of the JDK-specific versions. But you have to change your dependency either way, so I recommend you go with kotlin-stdlib-jdk7, or if you plan on using Java 8, kotlin-stdlib-jdk8
The newest versions of the dependencies can also be found here. jdk7, jdk8, and the version-unspecific stdlib all follow the same versions (as per this edit - this could change in the future, but there'll likely be notices before that change happens), so whether you check jdk8, jdk7 or the regular one, all the versions should be universally available across the stdlib artifacts.
Note for other build systems
The same actual solution applies to other build systems as well, but the code is different. As there are a lot of build systems, I'm not going to include all of them, but the point is changing the artifact from kotlin-stdlib-jre[num] to kotlin-stdlib-jdk[num] (without brackets of course). Or, as mentioned earlier, kotlin-stdlib.
Independently of the build system, this bases itself on access to Maven Central and similar repositories. If your build system doesn't support this, and/or breaks with Maven-style conventions and repositories, you'll have to find what works for your build system.
TL;DR:
Use org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version or org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version (depending on which version you originally used) instead.
Remove this line from the build.gradle:
implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
Add this line in the build.gradle:
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
Update the version build.gradle in project level:
kotlin version='1.3.0'
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.