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.
Related
which tool among those in above is used to solve what sort of problem? The simplified and straight to the point answer the better.
You can find some pretty good descriptions of each of these with a basic Google search.
In short, npm is a software repository. Grunt is a tool used bring together multiple javascript tasks into single commands. Webpack is a powerful module bundler, allowing you to bring together javascript, css, html from various sources (one being npm) and bundle them in such a way that you can be left with a single javascript module containing all the code you require.
The World's Largest Software Registry (Library)
npm is the world's largest Software Registry.
The registry contains over 800,000 code packages.
Open-source developers use npm to share software.
What is NPM # W3Schools
Grunt is a JavaScript task runner, a tool used to automatically perform frequent tasks such as minification, compilation, unit testing, and linting. It uses a command-line interface to run custom tasks defined in a file (known as a Gruntfile). Grunt was created by Ben Alman and is written in Node.js. It is distributed via npm.
What is Grunt # Wikipedia
webpack is an open-source JavaScript module bundler.[5][6][7][8] It is made primarily for JavaScript, but it can transform front-end assets such as HTML, CSS, and images if the corresponding loaders are included.[9] webpack takes modules with dependencies and generates static assets representing those modules.[10]
Webpack takes the dependencies and generates a dependency graph allowing web developers to use a modular approach for their web application development purposes
What is Webpack # Wikipedia
difference between grunt and webpack
grunt is stream management tools that perform functions required by users through task configuration, such as format verification, code compression, etc. It is worth mentioning that the code processed by grunt is only replaced by local variable names and simplified. Nothing has changed, it's still your code.
While webpack has carried out a more thorough packaging process, and is more inclined to transform the module grammar rules. The main task is to break through the gap between browsers, analyze, compress, merge, and package various static files that are not originally recognized by the browser, and finally generate the code supported by the browser. Therefore, the code after webapck has been packaged. It’s not the code you wrote, maybe if you look at it again, you can’t understand it anymore.
npm is more like providing building enviroment
npm is a package management tool installed with NodeJS. It can solve many problems in NodeJS code deployment. Common usage scenarios are as follows:
Allow users to download third-party packages written by others from the NPM server to local use.
Allow users to download and install command line programs written by others from - the NPM server for local use.
Allow users to upload their own packages or command line programs to the NPM server for others to use.
npm is more like providing build enviroment, but grunt and webpack is working as building tools.
I want to use a monorepo for our frontend app. We want to divide some react UI components into a package folder under "/packages/ui-components" and leave the app in an "/apps/app" folder and then have the app consume ui-components by importing it (simplified setup). We don't plan to release these packages to individual npm repos anytime soon, but just have the final app running.
I'm starting to worry a bit about how we can have the best workflow, and for some reason I cannot find this in my research:
Should the app consume the src-files from packages or instead compile each package to the dist folder and import only these?
Workflow wise we would like working in different packages seamless, so if someone edits in a package we would like these changes to immediately show in the App.
I see some pros and cons of using source-files compared to using a dist-output.
Pros of using src directly:
Better tree-shaking, as dependencies can be peer-dependencies and libraries that are used by multiple packages can be combined.
Smaller final bundle size due to webpack having better access to original data like full dependency-tree and common functions etc.
Faster development iterations with smaller projects as there's only one build and smart webpack could potentially only recompile a few changed files.
Pros of using dist:
More independent packages as they can contain their own build-pipeline.
Will be easier to import as less peer-dependencies and special webpack-config is needed
Ready to be published as a public npm package
Possibly faster build-time as only changed packages and main-app needs to recompile on changes (I assume webpack can do cache, so maybe this doesnt matter much)
I'm sure I'm missing a lot of details; setting up the good development flow is quiet complicated these days and I would like to make it as simple to use as possible for my colleagues..
TL;DR;
Should packages in a mono-repo build to their dist for others to consume, or is it better to import directly from src.
It is a matter of tradeoffs.
If you consume dist of your packages, this means that in order to "apply" changes inside your package you need to build, then consume it in the app.
Some even suggest publishing the package to the registry (public or private), this allows you more loose coupling between the app and the packages.
On the other hand, working on the src has "seem less" like advantages, but will require your app setup to support it, since it will be the one that compile the package's code.
Personally, I'm using the second method, my apps are consuming from the src, and it was not so trivial to configure to since most of the tools are ignoring code from node_modules by default (Like babel-loader, which will ignore transpilation of code inside node_modules).
Most of my code was based on next-transpile-modules source code.
I am trying to write my first set of npm libraries for a large, distributed application and am running into problems around how to manage dependencies. Npm has the concept of "dependencies" and "peerDependencies".
From what I read, peerDependencies are needed when you want to write a "plugin" where the consuming application is already expected to have the dependency installed on their end. For example, this might be building a plugin for webpack.
Then there are regular dependencies needed at runtime by a library. In my scenario, I am trying to write a library to abstract Authentication and Authorization away from the consuming application. This new library (lets call it #myapp/auth) has a dependency on the #auth0/angular-jwt library as it uses it to deal with JWTs. I want this library to be completely abstracted away from the consuming application and therefore not force that consuming application to install it manually.
With that said, it sounds like I need to add #auth0/angular-jwt to dependencies in my library and then add it to the whitelistedNonPeerDependencies which allows it to build.
This confuses me because the ng-packagr docs say that we should always use peerDependencies when possible. If this is the case, then why when you install a larger library like express, you simply run npm install express --save and you get ALL of the dependencies of express without manually installing each one.
What is the proper way to include package dependencies in a custom library that you do not want the consuming application to install themselves?
I'm new to the .NET Core framework and currently setting up a dashboard that uses Razor pages and some JavaScript interactions. For the few example projects I've created none of them came with a package manager from the get go, which imho is needed to keep the application maintainable. Coming from Node.js an Ruby on Rails background my default solution is NPM (or Yarn if you want).
I noticed however that Microsoft excluded Node from their base Docker images for .Net about 2 years ago (see here: https://github.com/aspnet/Announcements/issues/298).
This led me to questioning my solution to use NPM and I went looking for alternatives. I found that you can install Javascript libraries by wrapping them in Nuget packages and installing them via Nuget. But I'm hesitant to go this way as I've seen this pattern causing issues in Ruby on Rails. It adds an extra layer of maintenance and often the Ruby Gems where no longer maintained, meaning you're unable to move to the newest versions.
Then we have Libman, which is integrated into Visual Studio (https://learn.microsoft.com/en-us/aspnet/core/client-side/libman/libman-vs?view=aspnetcore-2.2) and draws packages from https://cdnjs.com, which I believe contains less packages (but according to Microsoft has everything you need). But their own blog (https://devblogs.microsoft.com/aspnet/library-manager-client-side-content-manager-for-web-apps/) says:
LibMan is not a package management system. If you’re happily using npm/yarn/(or something else), we encourage you to continue doing so. LibMan was not developed as a replacement for these tools. For example, the SPA templates (i.e. Angular and React) we ship for ASP.NET Core depend on npm and WebPack, and we have no plans to change that.
Then we're left with Bower, which is no longer an option, from https://bower.io/:
...psst! While Bower is maintained, we recommend using Yarn and Webpack or Parcel for front-end projects read how to migrate!
So I wonder, for a monolith app, is NPM or Yarn still the right choice and if so, why did Microsoft decide to exclude Node from their base images?
You mentioned LibMan which works just fine, but you need to configure it to download packages from unpkg which is a CDN for NPM and should contain everything that you can find on npm.
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.