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).
Related
I have a flutter application running on the Dart programming language. I have published an npm package that I want to use in my flutter application. Is there any way I can use the existing npm package in dart or somehow automatically convert npm package to dart package?
Dart and Javascript are different programming languages. While it might be possible to transpile you lib from js to dart, it is not easily doable, nor maintainable, and most likely not generalisable.
Unless you are comfortable with both languages and their limitations, you should not try to convert an NPM package to some Dart code unless you don't have any other choice.
I would advise you to rewrite the NPM package in Dart instead.
REMARK : this answer is based on the hypothesis that you don't want to integrate JS code in a webview but actually use the code inside the Dart VM.
It really depends on what you are going for,
Are you compiling your flutter app for web ?
Dart's JS library might be what you're looking for...
Are you going to compile for Android?
Then there's Android JS, Flutter_liquidcore, Interactive_WebView.
It Really depends on what you are expecting the application to compile to.
But don't expect native app experience...
We converted a fairly large js library to dart (manually) it was surprisingly easy as the two languages are very similar.
Tl:Dr: Use a WebView or run a Node/Deno/SpiderNode subprocess.
Let me answer the title of your question; you're going to have to wrap it in a webview or a node.js subprocess that can communicate over IPC using something like DBUS. This is cutting edge hard experimental tech as of 2021.
If it's a small we'll tested package, you could babel transpile it to Dart and automatically run the tests.
if it's a large package like Nuxt, forget about it, or put it in a WebView.
If it's your own package, consider translating it to Dart and then transpiling to JavaScript. It's Trivial to go from Dart to readable Node/ES2021.
But do you want to really use Dart for everything? Will the community for Dart be as strong as the Trois, Vue, WebXR typescript community in 5 to 80 years?
My advice would be to use Dart for what it's good for, client side JavaScript. And use well tested packages that can transpile from TypeScript to Dart, or a webview.
Could you use glue subprocesses to run node/deno/spidernode? see the Termux F-Droid debacle, where if you want to run a Node server on the latest version of Termux, you can't use the Google Play Store, but F-Droid. Basically, JIT will make your App Store approval process slower, but they will only be able to ban it from a policy standpoint, not from a technical one. You should not use npm install, but instead bundle the installed modules with the released app build.
How does the deprecation of JIT play in a world of Fuku native like PWA's and Spectre? From a security perspective, deploying to Kotlin/Swift is a narrow minded way of outsourcing the responsibility of making compiler patches happen, you should be building at least one a month, or leave the business. From a privacy perspective, the handshakes and huristic privacy protections will come to PWAs as hard as they will for binary apps.
I should clarify that I'm not that experienced with front-end tools, so I'm sorry in advance if I'm asking something obvious and stupid.
So far I've been using bower for front-end and npm for server-side, although each of the tools mentioned has its advantages and by that I mean flat dependency management of bower (reduces load from the client) and nested dependency management of npm (helps with versioning), it has become quite cumbersome to use so many tools (webpack, browserify, etc.). I may've been using these tools the wrong way and could've used either of them with some option (not known to me) and have been only scratching the surface, I just took this answer as my rule of thumb and have been doing so ever since I've read it. It would be great if I could reduce at least these two to one.
Lately I've become curious about yarn and with all the hype around it, it seems as if it has been doing a good job and as if it will replace npm completely. As I've read the docs I've discovered the --flat option and that made me wonder if it would be possible to use it as bower replacement as well? If so, does it mean I could have either flat or nested dependency manager (by just having multiple JSON files for back- and front-end)?
I would really appreciate if someone could point me in the right direction!
It depends on your exact use case, but... probably.
Currently, the major trend seems to be towards module bundlers such as Webpack and Browserify (and hence either npm or Yarn) and away from Bower. You can read an excellent overview of the situation at NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack, along with some reasons why you might want Webpack instead of Bower.
At the minute, you're probably using HTTP, where it works out faster to have one JavaScript bundle file rather than lots of source files (as would occur with Bower). That's why Webpack and Browserify are so popular (among other reasons) — they should increase performance and simplify development a lot.
Side note: HTTP/2 will diminish the value of module bundling, because multiple requests will become far less costly. See What is the value of using Webpack with HTTP/2 for a more detailed description of the issues involving HTTP/2.
If you use npm or Yarn, it shouldn't really matter if the dependencies are nested—your frontend dependencies will all be bundled anyway with Webpack/Browserify, so the main cost of using nested packages is that it takes up more space and more download time.
Since npm v3 and Yarn can do flat installs, there shouldn't be any issues with that anyway. In short: you probably can do it, and many other people are doing exactly that.
In recent days, there is an upward trend in the popularity of Yarn and its mainly due to couple of things different from npm.
One, it’s 100% deterministic i.e if you run yarn from any state, any time, 1000x times, it will still work the same way all the time. npm’s installs are nondeterministic. If you run it from various states, it will install different ways.
Yarn does some better caching too. In fact, it does it so well you’ll see a significant reduction in your install times. You can see 10x reduction in install times for big application.
Yarn also locks down your dependencies by default. It’s possible to do this with an npm shrinkwrap command but if you’ve ever had to maintain one of those, it can be messy.
I use npm scripts a lot for my javascript/node projects (npm start, npm test, and npm run build and others), and I was wondering if there is something similar for elm-packages, or if we should use npm scripts instead, and if I have to do it, why do we need a package.json and a elm-package.json?
The quick answer is that (as of May 2017) there's not support for this in elm-package.json.
As for the future: Evan Czaplicki has said on elm-dev mailing list that the file format and functionality will get revamped a little bit (probably with the 0.19 release), but most probably mainly with regards to application vs. library distinction. Based on that, I don't think elm-package.json will get this functionality anytime soon.
I think most devs have some node stuff running to handle their dev environment (e.g. webpack stuff) so you will always have package.json available for such scripts anyway.
There is a question about whether elm should embed its dependencies within package.json but, while most dev instances would have package.json, anyone just trying out with elm-reactor would not. So I think the present situation is here to stay, and enables you to do what you want.
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.
Lately I have been wondering if there is any way to use bower or npm only as a consumer.
Let’s say I am not really interested on developing the package further, but simply using it on my website/application.
So as I would first think:
npm install jquery
I have tried with the flag --production but the same structure was downloaded.
However, that brings me a huge tree of files and the only one I would need is the jquery/dist/jquery.min.js file.
Same goes for bower:
bower install jquery
Again, an expensive list of files, including src folder with a lot of dev-only related files.
I am sorry if I am wrongly assuming package managers behaviour here, but it would be interesting to know how to use these package managers as a simple end-user instead a developer in order to keep my project dependencies updated.
At the moment, I feel that it's just too much for what I need, and that by simply copying jquery.min.js over to my project src folder, it would be much cleaner/simpler.
If the concept of both npm and bower is different and someone can point it out it would be appreciated as well as any tips for an alternative package manager that only imports essential production files.
Apparently Volo does exactly what I was looking for following a concept where JS libraries should be kept as one single JS file.
Here, more information about the project’s design goals.