I am studying React.js., and I have started by setting the project folders to try some codes. But, some terms are confusing me as a beginner. One of them is "dependency." When I search for it, the result is only related to dependency injection stuff, but what is the "dependency" itself?
A dependency is some third-party code that your application depends on. Just like a child depends on its parent, your application depends on other people's code. A piece of code becomes a true dependency when your own application cannot function without it.
If you want to look at the dependencies you're using, you can find them in the package.json file under the dependencies key.
Well, dependencies are those things that you need to install and import for doing specific things, for example, if you want to add routing(moving from one page to another which changes your URL) in your react project then you need to install react-router-dom dependency by doing
npm install react-router-dom
A dependency is just a package that your project uses.
Very few javascript projects are entirely self-contained. When your project needs code from other projects in order to do its thing, those other projects are "dependencies"; your project depends on them to run.
When you install third-party packages via npm install <package>, you're adding a dependency.
Your project's package.json file includes a list of your project's dependencies.
Related
all! I currently met a difficulty with my project. I want to modify the code of a component from a UI library (like Semantic-UI, Material-UI). What I do now is just edited the code from the node_modules. But the reality is no matter how I change the code from node_modules, my project will not be affected. Why this will
Well that's because most modules have build process which you need to run before using them. Also editing a module directly is not a good idea because any change you do to them is guaranteed to be lost after next npm install.
As Vuetify is a MIT licensed, I suggest to fork its GitHub project and then publish it as your own npm package.
I am trying to breakout a couple of Vue.js components from a primary application into an npm package stored on a repository. This package can then be imported and used across two separate sites. I am using Webpack to bundle everything but have had a few queries about the layout that should be used.
Seeing that things like Vue.js and Vuex will installed as dependencies on the main application, I know that the package will have access to these once installed on the two main applications.
My primary confusion is how do I deal with dependencies that belong to the package only, do I bundle this as part of the webpack and will running npm install on the applications automatically install the 'dependencies dependencies' if you will? Is there a general standard for these things?
The simplest thing to do is list them in your dependencies section in package.json. The package manager tool you're using (usually either npm or 'yarn`) will take responsibility for deduping the dependences, so if your parent app and your subproject both have the same dependencies, you'll only end up with one copy in the final bundle.
I would strongly suggest that you be looser on version numbers in the component projects then you are in the parent project. So in the parent maybe you say the dependency is "vue": "1.2.3" and in the component project it's "vue": "^1.1.0" or something along those lines. This way the parent can control the specific versions and your component picks up the actual version from the parent.
Ember CLI applications have a package.json that lists everything as a dev dependency. Even stuff that is needed in the app's production version. For instance packages like ember and ember-data are installed as devdependencies.
As a reference, here's a sample of what I'm talking about: https://github.com/ember-cli/ember-new-output/blob/master/package.json#L17-L38
What's the reason for this?
In the context of application:
As #Lux mentioned in the comments, you don't need them after the build.
The output of the application is the build, that is supposed to be the final product. Further, you generally don't depend on another application. You generally depend on a package or an addon.
In the context of addons:
I think there is an opinion to display all of the addon dependencies of an application at the application's package.json file. By doing this way, you can prevent that an addon unintentially adds a js file to the build.
As a result, the ember way of managing dependencies is to leave all of your dependencies at your devDependencies and add all of the dependencies of the addon to the application's package.json with default blueprints. So the end user can tune them.
I'm trying to build an application that have to run on Windows(PC), Android and iOS.
For this, I will use Electron (for Windows) and React Native (for mobile plateforms). Both will be built with React and Redux. This way, I will be able to implement the logic in Redux reducers and middlewares and use them in both projects.
From now, I have done a POC for the Electron app using webpack. The reducers are currently directly in the app code. I want to extract the Redux relative code in a seperate package to allow me using it in a the React Native project.
I can make an npm package for my Redux module containing the reducers and the middlwares but this way, when I will compile my application, webpack will not compile my seperate package, it will use the precompiled version.
So What I want is to be able to make a separate package but still compile it at application compile time (because it is still in developpement and the dev is very closely related to main application dev).
Do I have to do it only with npm or with webpack as well ?
I'm pretty new to the Javascript dev stack.
I think you have different ways to handle that problem.
You can use NPM package. But in code of package, you will store not only original source code, but compiled code too. I mean before publish that package, you'll need to compile it in normal ES5 code.
I think you can use submodule system provided by Git. You should have separate repository with common code of your reducers. And in each project (Electron, RN, etc.), you will have a directory with git submodule. Webpack should compile code in that directory normally without any problems.
UPD:
About submodules you can read nice article here: https://git-scm.com/book/en/v2/Git-Tools-Submodules#Starting-with-Submodules
In few words, in project it will looks like:
cd yourProjectFolder
git submodule add https://github.com/TalAter/awesome-service-workers submoduleDirectoryName
It will clone repository to your project, and create .gitmodules file. Code from submodule will not exists in current project repository. In remote repository it will contain only link to submodule, but on your machine, you will have full code and you will be able to compile it.
There are a ton of packages out there that have this all bundled up but I dont like the way they set up the projects and such so I was reading the Reactjs docs on installing with npm and my confusion is:
After installing it using npm install react or adding react to
package.json
Do I add this to the "devDependencies": {} or ...
for the require statement to work, do I need to include requirejs?
Can I just do grunt serv to start everything and auto compile the jsx or do I need to do this? (it seems like that might be answered for me ..... but how can I get it to auto compile the jsx when I run grunt serv)
I ask these questions and state I don't like the existing yo ... commands for this because they don't play nicely with bacbone.js So I was going to set this up my self. if there are any repos out there for yeoman that do this for me please point me to them.
dependencies vs devDependencies: for npm package.json, devDependencies are mainly used for the tooling around working on the project itself: testing tool chain and project building modules, for example. Things you'd often see in there: Mocha, Grunt, etc. So mostly for repo contributors and alike. As a consumer of React, you'd put it in dependencies, which are for modules that your code actually needs in order to work.
require isn't for requirejs. The naming clash is unfortunate. require() is part of CommonJS. Node uses CommonJS. Browserify too. Here, it's assuming that you're using Browserify, or maybe doing server-side React with Node.
I'm not sure what you've set up to use with grunt serve. There's nothing magical that makes it work by default. You do need to do what the link said. The --watch option will look for changes to your files and auto compile the jsx to js.
Hope that helps!