I am currently creating a package which I will publish on NPM. My package uses React but I don't want to add it as a dependency in my package to avoid consumers of my package from ending up with multiple versions of React in their projects (which will always be React projects as my package is React specific), thus bloating their projects unnecessarily.
Therefore I am going to add React to my package as a peer dependency.
My package uses React.Component, React.isValidElement and React.createElement. Therefore I need to find the oldest version of React which supports these features and make this version the minimum version in my peer dependency.
I am struggling in determining how to determine which version of React to use. If anybody is able to offer advice on how to work this out then I'd greatly appreciate it.
According to the changelog, the minimum version you can depend on is 0.13.0. I would recommend setting your dependency version to >=0.13.0. It would be best to use a CI tool like Travis to test your build on many versions of React (starting at the minimum) to ensure that you don't accidentally break things by relying on newer features.
Introductions
Component in 0.13.0 (Support for using ES6 classes to build React components)
isValidElement in 0.12.0 (React.isValidComponent --> React.isValidElement)
createElement in 0.11.12 (Added React.createElement API in preparation for React v0.12)
Related
I am getting error:0308010C:digital envelope routines::unsupported for a serverless package command.
Have referred to multiple SO questions and other documents. Most of them suggest the following:
Downgrading node version to any LTS lesser than 17:
Downgrading the node version creates a lot of library compatibility issues. For example, one of the many errors I get from the node-fetch library during webpacking is Can't resolve 'node:util' in <project-directory>\node_modules\node-fetch\src
Set Node to use openssl legacy provider: Since the newer versions of node use the encryption algorithms supported by the newer openssl but the libraries in the project still (guessing) only support the algorithms supported by openssl 1.1, which is the main reason behind the ERR_OSSL_EVP_UNSUPPORTED issue, we need to override node's default encryption algorithms to the ones supported by openssl 1.1 by setting NODE_OPTIONS to --openssl-legacy-provider. This solution is working for react projects or even frontend frameworks like ionic where the node options can be easily overridden in the scripts in package.json or the documentation of ionic tells us how to set it so that it can pick it up during build stage. But this does not work for backend framework libraries like serverless. I am not sure how the node options can be overridden for serverless because setting it as an environment variable is not working nor can I find any documentation.
I currently have a React based website. I want to start on the process of converting the website to also work natively through react-native. I understand that I will need to re-build the UI for the native version.
My goal however is to leave both versions in the same node project so I dont have to update my non-view based code separately for both versions of the code base.
Is it possible to add the dependencies and files necessary for react native while not having to separate the native code out into it's own completely separate project and if so how?
Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.
I understand that packages hold several modules, but I'm starting to get confused as to if packages and modules are dependencies. Also, libraries to me maybe seem like packages you install via NPM, Nuget, RubyGems, Bower, Homebrew, or Chocolatey. So are libraries packages? Dependencies are something you need to load within your application, to have a certain functionality, but aren't some libraries(jQuery) seen as a dependency? So yea, what are the differences between these concepts?
Libraries are just a bunch of code anyone can use. For example, React.js is a JavaScript library for building front end components.
If I decide to use this library in my app, then React will become one of the modules (aka an installed instance of the library) that my app depends on. So dependencies are pretty much all of the libraries your app depends on, in order to run the way you expect it to run.
I asked the same question you did about dependencies, and I learned that it's a matter of understanding how these terms relate to one another rather than finding isolated definitions for each of them.
Hope this helps!
Basically a package is a pack with some features which fullfills some functionality of your app.
Once you install any package using npm then the package is installed as a dependency in your app inside your package.json file along with its modules(aka libraries consist of classes) stored inside node_modules folder.
I hope its clear now.
I am new to angular2 and I have never used angular1.
I have been trying this tutorial https://angular.io/guide/quickstart and
i wonder if all the recommended dependencies are really necessary because my project size gets big after 'npm install' (more than 100Mb).
You won't necessarily use all of the #angular dependencies during the Quickstart, but if you continue on with their tutorial and as your app gets more complex, you will definitely utilize them.
The other packages are necessary. They consist of typescript compilers, libraries for Observables, and more Angular 2 features. Here is a quick read for info on some of these.
If you're using angular-cli, calling ng serve will also run a series of automated tests that depend on packages.
I'm creating a npm package that only contains Sass, a small framework. I only want this package to contain the Sass (and a few grunt plugins) so that someone can install and build it without installing the documentation.
But in the case where someone wants to contribute to the project having only the Sass files isn't all that helpful. They would need the documentation (or an example) to view the changes.
So I would like 2 packages; 1 for the framework and 1 for the documentation.
The documentation package would require the framework, the framework package may or may not require the documentation. (You would never update the framework from documentation, only the documentation, but the framework is needed.)
Documentation required = wanting to contribute to framework
Documentation not required = just wanting to use the framework in a project
Basically, I want to give the person installing the framework the option of getting the docs or not.
Is this possible using dependencies vs devDependencies vs peerDependencies?
Thanks!
From above:
To someone who wants to contribute, wouldn't Github be a better option? They could just clone the repo instead of installing it from npm. You could use npmignore to ignore all the documentation from npm package, which will still remain on Github
Thanks #laggingreflex