Hi I'm creating my first NuxtJS app but while creating it I see many deprecation warnings by NPM. I know this won't stop my app from running but I'm just wondering why so many deprecated packages out-of-the-box here...
Can someone explain me what is going on? Some of the warnings are also pretty scary if you're just starting a new project such as security concerns and packages no longer maintained...
Related
I'm responsible for maintaining a bunch of npm packages. Specifically, I am a maintainer of Apollo Server. Our latest major version combines over a dozen apollo-server-* packages into a single #apollo/server package.
We are going to use npm deprecate to mark the old packages as deprecated to help people find the new one. But I'm running into a bit of a pickle.
If my testing is correct, npm deprecate PACKAGENAME is actually equivalent to "individually mark all current versions of PACKAGENAME as deprecated". But if we then go ahead and publish another version of the package later, the new version appears to not be deprecated.
While we want people to upgrade to the new package, we still may publish some versions of the old package, for security fixes and the like. And unfortunately that will often mean publishing over a dozen separate packages.
So if I'm not confused, this will mean we have to re-run npm deprecate after any publish, or else the package will effectively end up non-deprecated?
So my next thought was to do the deprecation in a shell script, to either be run in CI post-publish or manually by a developer. But unless my testing was incorrect, it does not look like you can use NPM_TOKEN=xxx npm deprecate at all (whether it's an automation token or a publish token): I get an error that the package does not exist. So the script will have to be run manually... and will require me to enter dozens of OTPs.
So my question is: if I have a project that consists of dozens of packages that I want to keep deprecated even if I publish patches in the future, do I really need to maintain a shell script that runs npm deprecate dozens of times and requires me to manually enter dozens of OTPs? Or is there an easier way?
I posted this question yesterday, but apparently worded it badly, so I'm trying again.
I'm working on a project that had been closed for a couple of years and reopened. During that time, a large number of the included node_modules have gone out of support (or at least the versions being used), React Native has been updated several times, new rules came out for building iOS projects, etc. leaving the project in a pretty broken state.
The previous team that worked on the project didn't leave much in the way of documentation, and we're stuck figuring out the details on our own.
There are two of us on the UI development, and we're able to build the project as-is using all of the old components. However, as soon as we start upgrading anything, we run into conflicts.
I've spent a good bit of time (several different times combined) trying to find a way to get the upgrade started, but everything I've tried runs into conflicts.
For purposes of clarity, he problems that I encounter include:
npm reports ERESOLVE Unable to resolve dependency tree
many errors (hundreds) come out of the XCode build - version compatibility, not allowed to use deprecated components, legacy build system outdated, conflicting pointer assignments, etc
All tools need to be upgraded (Node, npm, Android Studio, Xcode, React, React Native, Gradle, etc
Is there somewhere I can find an article or tutorial or something with a step-by-step, repeatable process for creating a project from scratch and adding the required components in an orderly way so that I can upgrade the whole process at once?
Also, I know that a lot of open source projects support their products with paid services, but that doesn't appear to be the case with React Native as far as I can tell. Is there somewhere we can find a project / build expert to come in and work with us on this?
Any help would really be appreciated!
Thanks in advance!
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.
Is anyone else having an issue after running the following on a react-admin 2.4.0 project?
npm build
serve build
The pages have some odd formatting, as if styles are getting clobbered. It is quite unusable in my project.
I went back to 2.3.0 and all of the issues were fixed. Before making recreating and reporting in github, I thought I would start by asking here.
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.