Related
I use underscores.me as a starter template for any new theme I create. Previously I just used dart-sass to compile my scss files into css. However, I'm starting a new project and would like to use the package.json file included with underscores (Sassified and with Woo Commerce), but I'm a bit confused about the included CLI commands that are in the package.json.
The following scripts are taken from the generated package.json file:
"scripts": {
"watch": "node-sass sass/ -o ./ --source-map true --output-style expanded --indent-type tab --indent-width 1 -w",
"compile:css": "node-sass sass/ -o ./ && stylelint '*.css' --fix || true && stylelint '*.css' --fix",
"compile:rtl": "rtlcss style.css style-rtl.css",
"lint:scss": "wp-scripts lint-style 'sass/**/*.scss'",
"lint:js": "wp-scripts lint-js 'js/*.js'",
"bundle": "dir-archiver --src . --dest ../_s.zip --exclude .DS_Store .stylelintrc.json .eslintrc .git .gitattributes .github .gitignore README.md composer.json composer.lock node_modules vendor package-lock.json package.json .travis.yml phpcs.xml.dist sass style.css.map yarn.lock"
}
Here are my questions:
What is the main difference between "watch" and "compile:css"? If one watches Sass files for changes and then compiles to CSS, how is this any different from compile:css? Should they both be running?
Are these all scripts that should be running simultaneously during dev/coding? Or, are some supposed to be run only at specific times, such as "bundle" when I need to recompile certain files like JavaScript to compile a production version?
If these are not meant to all be running simultaneously, such as the "bundle" command, when is the ideal time to run this script and once it's run should I stop it or simply let it keep running in the background?
Would I only use "compile:rtl" if using languages written from right-to-left?
Since the linting commands check for errors in SCSS and JS, should those be run simultaneously during development as well, or only when you go to check work prior to deploying to production?
So assuming I do not need to compile:rtl, how would one use the remaining 5 scripts most effectively and efficiently?
I've stumbled across an issue while using NPM 7 workspaces and Babel where I can't wrap my head around the best way to be able to import from src/ during development but use dist/ during production.
Apologies for my awful explanation, I'll just do an example (this excludes config files and such for brevity):
My project structure is like so:
- /
- lambdas/lambda-a
- src/
- package.json
- packages/package-a
- src/
- package.json
- package.json
I have my main field in packages/package-a/package.json like so:
{
...
"main": "src/index.js",
...
}
Which means I can import stuff from packages/package-a just fine in lambdas/lambda-a/src/index.js:
import { thing } from '<package-a>'
However, by having the main field pointing to src/index.js, this isn't going to work in production, and if I change the main field to dist/index.js I can no longer import in lambdas/lambda-a during development without running a build after every change.
Does anyone have a solution for this? Or, more likely, can anyone point out where I'm being a muppet?
The workaround I use is to replace src/index.js before building and replacing it again after building/packing is done. This is neither elegant nor "how you should do it" (AFAIK), but it works for me in a small project.
I use npe because it's lightweight but there are similar (or more powerful) packages out there.
Example (packages/package-a/package.json):
...
"devDependencies": {
"npe": "^1.1.4"
},
"scripts": {
"build:before": "npe main dist/index.js'",
"build": "(npm run build:before) && (if exist dist rmdir /s /q dist) && (babel src -d dist --copy-files) && (npm pack) && (npm run build:after)",
"build:after": "npe main src/index.js",
},
...
But I'm also still searching for a more "official" way...
I have created a React component inside a project that I'd like to use in multiple projects. At the moment, I only care about doing this locally and for development. The React Component is rendered into the root div, the project uses webpack and babel to transpile JSX, ES6 and some ES7 features into a bundle.
I thought it would be simple to export this component such that I can simply run npm install MyComponent and begin using it in a fresh project. However, I find it isn't so straight forward. In particular, I've been reading for hours and hours and only seem to be getting more confused.
If my end goal is to keep developing 'MyComponent' in its containing project, while using 'MyComponent' in any number of other local projects, what are my options? The first thing I did was change the main key of my package.json to /src/components/MyComponent and run npm pack. This produces a tgz file I can install via its absolute filepath in other projects. However, I found that the es6 and jsx was not being transpiled and so my client projects would be unable to parse MyComponent. I then used webpack to transpile into lib/MyComponent, but when I have import MyComponent from './path/to/MyComponent-1.0.0.tgz I'd only see {} (an empty object) in the console.
Searching for solutions to my problem turn up many different approaches pulling together NPM, Grunt, Gulp, Babel, Webpack, etc.. And I am worried it will be many many more hours (days?) before I can grind that down to something understandable.
Given my requirements, what is the simplest solution I can implement to 1) compile down my React Component to the simplest to import module 2) import it into any local projects 3) continue to develop the package in the original host project and have changes easily propagate to client projects.
In general, if you're going to begin creating React components as separated packages (which is a great pattern, for all the reasons you've already mentioned) - you're going to need to get at least a bit familiar with webpack and babel. There's a ton to learn here, but let me try to point you in the right direction:
// webpack.config.js
/* eslint-disable */
const path = require('path')
const webpack = require('webpack')
const ENVIRONMENT = process.env.NODE_ENV
const PRODUCTION = ENVIRONMENT === 'production'
const SOURCEMAP = !PRODUCTION || process.env.SOURCEMAP
const library = 'your-lib-name' // << RENAME THIS <<
const filename = PRODUCTION ? `${library}.min.js` : `${library}.js`
const plugins = []
if (PRODUCTION) {
plugins.push(
new webpack.DefinePlugin({
'process.env.NODE_ENV': JSON.stringify(ENVIRONMENT),
}),
new webpack.optimize.ModuleConcatenationPlugin(),
new webpack.optimize.UglifyJsPlugin({
minimize: true,
output: { comments: false, semicolons: false },
sourceMap: SOURCEMAP,
})
)
}
module.exports = {
devtool: SOURCEMAP ? 'source-map' : 'none',
entry: `${__dirname}/path/to/your/component.js`, // << RENAME THIS <<
externals: {
'react': 'react',
'react-dom': 'react-dom',
},
module: {
loaders: [{
test: /\.js$/,
loader: 'babel-loader',
exclude: /node_modules/,
}],
},
output: {
filename,
library,
path: `${__dirname}/lib`,
libraryTarget: 'umd',
umdNamedDefine: true,
},
plugins,
}
I know that looks like a bunch - but it handles the majority of what you're going to want. In specific:
If you specify NODE_ENV=production when building, this will uglify/minify your package, and do some other trimming which you may want later.
Building with this script will output a sourcemap, which you can use with dev tools to inspect your minified code in the debugger window, among other things.
This marks react and react-dom as externals - which means they won't get bundled up and packaged inside your bundle. This is great - because it means you won't get 2+ copies of react's filesize just because you've imported your own component!
To use it, though, you now need some package.json love.
package.json
{
"name": "Your Name",
"version": "0.0.1",
"description": "This is my awesome react package!",
"main": "path/to/your/component.js",
"author": "Your Name",
"license": "MIT",
"repository": { /* Your Repo Info Here */ },
"dependencies": {
"any-packages-you-need-included-in-builds": "^1.0.0"
},
"devDependencies": {
"babel-cli": "^6.22.2",
"babel-loader": "^7.1.0",
"babel-preset-es2015": "^6.22.0",
"babel-preset-react": "^6.22.0",
"prop-types": "^15.5.10",
"react-dom": "^15.6.1",
"webpack": "^3.0.0"
},
"scripts": {
"build": "yarn prebuild && NODE_ENV=production webpack",
"prebuild": "mkdir -p ./lib && rm -rf ./lib/*"
}
}
Obviously, you can have a lot more here if you need it - such as other babel-plugin-* plugins that you use in your transpilation, other packages, etc.But this set will let your webpack build run. Note that the scripts here assume you're using yarn - so that you can run yarn build, and that you're on a posix system, for mkdir to work. If you're on windows or not using yarn, just update the scripts accordingly.
The rest is just learning to publish your package to npm or another package repository. Primarily, that's just setting the version number in package.json to something new (npm version) and then publishing (npm publish). You will have to have an npm account for this, of course - and be logged in (npm login).
Once you've published to npm you can just yarn add your-package-name.
Remember, though - we marked react and react-dom as external - so in the consuming package, you'll need to make sure they're available as window.React and window.ReactDOM - or you'll need to include the component directly from node_modules/your-package-name/path/to/your/component.js
You don't need to npm pack a package to use it. If you make your component into a git repo and put it on Github, you can use NPM to install it directly from Github by using npm install alex/mycomponent where alex is your github username and mycomponent is the repo name. Re-running that command will re-install from Github, in case you make changes to the repo.
Once you're happy with the component, you can upload it to the NPM registry to install like any other package (npm install name). Using Github at first makes it a bit easier to develop.
Webpack might not compile things from node_modules by default. Usually, packages are pre-compiled before being published anyway, but you should be able to configure webpack to build your 'packaged' component, along with the rest of your app. Maybe this will help: https://stackoverflow.com/a/38008149/7486612
In order to push react libraries into NPM, you may need some boilerplate which will install and convert many things for you (and you can still use your current react module as the main source, just follow the guides at the end of my answer, then you will surely get all the ideas)
Or you can also refer to my previous answer to a similar question:
Issue with publishing to npm
=====
I've also pushed several react libraries successfully into NPM:
https://www.npmjs.com/~thinhvo0108
=====
Your github repositories' folder structure should also look like mine:
https://github.com/thinhvo0108/react-paypal-express-checkout
=====
Useful tutorial below here:
(boilerplate source) https://github.com/juliancwirko/react-npm-boilerplate
(author's article) http://julian.io/creating-react-npm-packages-with-es2015/
Start by looking at existing component library, eg Material UI.
Specifically check out npm scripts they have (see package.json):
"build:es2015": "cross-env NODE_ENV=production babel ./src --ignore *.spec.js --out-dir ./build",
"build:es2015modules": "cross-env NODE_ENV=production BABEL_ENV=modules babel ./src/index.js --out-file ./build/index.es.js",
"build:copy-files": "babel-node ./scripts/copy-files.js",
"build:umd:dev": "webpack --config scripts/umd.webpack.config.js",
"build:umd:prod": "cross-env NODE_ENV=production webpack --config scripts/umd.webpack.config.js",
"build": "npm run build:es2015 && npm run build:es2015modules && npm run build:copy-files && npm run build:umd:dev && npm run build:umd:prod",
That's example of very involved and high quality component library, that makes sure that regardless of your build pipeline you'll be able to use it.
Setting up build process with webpack might be cumbersome, but don't concentrate on that too much from the begining, and cover cases that are most straight forward to you.
Also check out https://storybook.js.org/ while working on your components.
package.json:
...
"name": "mypackage",
"main": "src/index.js"
...
Directory structure:
|- src/
|--- index.js
|--- other.js
I can require src/index.js with require('mypackage');, but how can I require src/other.js?
If the answer is require('mypackage/src/other');, is there a way to make it so I can require it with require('mypackage/other'); (i.e. teaching node what the source file directory is of your module?
AFAIK You'll have to explicitly expose it in the root:
Directory structure:
|- src/
|--- index.js
|--- other.js
|- other.js
Then in /other.js
module.exports = require('src/other.js');
Now you can do require('mypackage/other')
I'm currently looking into the exact same thing.
Package.json has a property called 'files':
http://blog.kewah.com/2014/npm-as-a-front-end-package-manager/
https://docs.npmjs.com/files/package.json
The "files" field is an array of files to include in your project. If you name a folder in the array, then it will also include the files inside that folder.
But I have yet to find how to do a import/require of such a file.
I don't really see another point in listing these files other then to be able to import/require them?
I was able to import a file from a package if it was listed in this files array.
{
"name": "local-ui-utilities",
"version": "0.0.1",
"description": "LOCAL UI Utilities",
"main": "index.jsx",
"author": "Norbert de Langen",
"license": "none",
"dependencies": {
},
"files": [
"/colors/sets/variables.css"
]
}
I'm able to import the css file from the package using postcss-import:
#import "local-ui-utilities/colors/sets/a.css";
This probably isn't your use-case, but postcss-import just uses npm under the hood. So This should work for your use-case as well, I would think.
This question and accepted answer seem related:
Node/NPM: Can one npm package expose more than one file?
You'll have to explicitly expose the file in the root folder, but many projects (including older versions of lodash) do this as part of a pre-publish step. In fact there's a package that does exactly what #Creynders suggests, adding module.exports = require('./path/to/file') files in your root folder. A while back I wrote up a guide on getting started, but the gist is pretty simple.
Install
npm install --save-dev generate-export-aliases
Configure
{
"name": "my-package",
"scripts": {
"prepublish": "generate-export-aliases"
},
"config": {
"exportAliases": {
"other": "./src/other"
}
}
}
Use
const other = require('my-package/other')
DISCLAIMER: I'm the author of the package
Edit
Don't use prepublish anymore. Instead, use prepublishOnly.
My own approach to the solution:
As no one has an idea of how to perform the desired behaviour, we can't stand still, the best answer now is:
Solution 1:
From Patrick solution, and his package generate-export-aliases: we can add some npm scripts to automate the whole publish process.
Either you write your code directly in commonjs inside ./src/ subdirectory or you used some new shining ES feature transpiled in ./dist, you will have your module files to be exposed, so add npm scripts:
"scripts": {
"expose": "generate-export-aliases",
"prepublishOnly": "npm run expose",
"postpublish": "git reset --hard HEAD"
}
Or a more save scripts
"scripts": {
"expose": "generate-export-aliases",
"prepublishOnly": "git ceckout -b prepublish-expose && npm run expose",
"postpublish": "git add . && git stash && git stash drop && git checkout master && git branch -d prepublish-expose"
}
Solution 2: Without generate-export-aliases
You can use gulp task runner (transpile if needed and put the files directly in the root dir, no need to copy or move again).
Indeed, this is the exposing step, you can keep prepublishOnly and postpublish scripts unchanged and just change the expose script. Save time and build in the root dir directly.
From node 12.7.0 there is the [exports][1] property of the package.json that can help you.
{
"main": "./main.js",
"exports": {
".": "./main.js",
"./other": "./src/submodule.js"
}
}```
If you have a lot of submodules and you want to export all files you can use a [subpath pattern][1]:
```//package.json
{
"exports": {
"./*": "./src/*.js"
},
}```
[1]: https://nodejs.org/api/packages.html#subpath-patterns
just import it as a simple file.
const otherfile = require('./node_modules/other_package/other_file.js');
I'm trying to follow a tutorial on NodeJS. I don't think I missed anything but whenever I call the process.env.NODE_ENV the only value I get back is undefined. According to my research the default value should be development. How is this value dynamically set and where is it set initially?
process.env is a reference to your environment, so you have to set the variable there.
To set an environment variable in Windows:
SET NODE_ENV=development
on macOS / OS X or Linux:
export NODE_ENV=development
tips
in package.json:
"scripts": {
"start": "set NODE_ENV=dev && node app.js"
}
in app.js:
console.log(process.env.NODE_ENV) // dev
console.log(process.env.NODE_ENV === 'dev') // false
console.log(process.env.NODE_ENV.length) // 4 (including a space at the end)
so, this may better:
"start": "set NODE_ENV=dev&& node app.js"
or
console.log(process.env.NODE_ENV.trim() === 'dev') // true
For people using *nix (Linux, OS X, etc.), there's no reason to do it via a second export command, you can chain it as part of the invoking command:
NODE_ENV=development node server.js
Easier, no? :)
We ran into this problem when working with node on Windows.
Rather than requiring anyone who attempts to run the app to set these variables, we provided a fallback within the application.
var environment = process.env.NODE_ENV || 'development';
In a production environment, we would define it per the usual methods (SET/export).
You can use the cross-env npm package. It will take care of trimming the environment variable, and will also make sure it works across different platforms.
In the project root, run:
npm install cross-env
Then in your package.json, under scripts, add:
"start": "cross-env NODE_ENV=dev node your-app-name.js"
Then in your terminal, at the project root, start your app by running:
npm start
The environment variable will then be available in your app as process.env.NODE_ENV, so you could do something like:
if (process.env.NODE_ENV === 'dev') {
// Your dev-only logic goes here
}
in package.json we have to config like below (works in Linux and Mac OS)
the important thing is "export NODE_ENV=production" after your build commands below is an example:
"scripts": {
"start": "export NODE_ENV=production && npm run build && npm run start-server",
"dev": "export NODE_ENV=dev && npm run build && npm run start-server",
}
for dev environment, we have to hit "npm run dev" command
for a production environment, we have to hit "npm run start" command
In macOS for those who are using the express version 4.x.x and using the DOTENV plugin, need to use like this:
After installing the plugin import like the following in the file where you init the application:
require('dotenv').config({path: path.resolve(__dirname+'/.env')});
In the root directory create a file '.env' and add the varaiable like:
NODE_ENV=development
or
NODE_ENV = development
As early as possible in your application, require and configure dotenv.
require('dotenv').config()
In UBUNTU use:
$ export NODE_ENV=test
install dotenv module ( npm i dotenv --save )
require('dotenv').config() //write inside the file where you will use the variable
console.log(process.env.NODE_ENV) // returns value stored in .env file
Must be the first require in app.js
npm install dotenv
require("dotenv").config();
In my case, I have a node app. The way I have structured it is that I have client folder and server folder. I had my .env file inline with these two folder. My server file needs the .env file. It was returning undefined because it did not live inside the server file. It was an oversight.
App
-client
-server
-.env
Instead I moved .env inside server file like so:
App
-client
-server
|-.env <---here
|-package.json
|-and the rest of the server files...
(before this - ofcourse have the dotenv npm package installed and follow its doc)
It is due to OS
In your package.json, make sure to have your scripts(Where app.js is your main js file to be executed & NODE_ENV is declared in a .env file).Eg:
"scripts": {
"start": "node app.js",
"dev": "nodemon server.js",
"prod": "NODE_ENV=production & nodemon app.js"
}
For windows
Also set up your .env file variable having NODE_ENV=development
If your .env file is in a folder for eg.config folder make sure to specify in app.js(your main js file)
const dotenv = require('dotenv');
dotenv.config({ path: './config/config.env' });
You can use the dotenv package from npm, here is the link: https://www.npmjs.com/package/dotenv
Which allows you to place all your configuration in a .env file
If you faced this probem in React, you need react-scripts#0.2.3 and higher. Also for other environment variables than NODE_ENV to work in React, they need to be prefixed with REACT_APP_.
For me, the issue was that I was using the pkg library to turn my app into an executable binary. In that case, the accepted solutions didn't work. However, using the following code solved my problem:
const NODE_ENV = (<any>process).pkg ? 'production' : process.env.NODE_ENV;
I found this solution here on GitHub.
In Electron Js
"scripts": {
"start": "NODE_ENV=development electron index.js",
},
If you define any function with the name process then that may also cause this issue.
Defining process.env.NODE_ENV in package.json for Windows/Mac/Linux:
Here's what worked for me on my Mac (MacBook Pro 2019, 16 inch, Big Sur):
"scripts": {
"build": "export NODE_ENV=prod || set NODE_ENV=prod&& npx eslint . && node --experimental-json-modules ./backend/app.js && gulp",
},
Using the export NODE_ENV=prod || set NODE_ENV=prod&& string may work in Windows and Linux but I haven't tested that.
If someone could confirm that would be great.
Unfortunately using the cross-env npm package did NOT work for me at all in my package.json file and I spend a long time on my Mac trying to make this work.
I also faced this issue.
I moved .env file to the root folder (not the project folder, a level higher) and it worked out.
Check it. it might help you as well
You can also set it by code, for example:
process.env.NODE_ENV = 'test';