When I enter $ webpack into my terminal I receive the following error:
webpack config
/Users/kristenmkulha/Desktop/react-help-queue/config/webpack/development.js
not found, please run 'bundle exec rails webpacker:install' to install
Webpacker with default configs or add the missing config file for your
custom environment.
I found a similar issue here: Webpack command in node brings /config/webpack/development.js not found and changed the deprecated babel-preset-es2015 to babel-preset-env and I already had the -loader suffix. These updates still result in the same error.
Here is my webpack.config.js:
const webpack = require('webpack');
const { resolve } = require('path');
module.exports = {
entry: [
resolve(__dirname, "src") + "/index.jsx"
],
output: {
filename: 'app.bundle.js',
path: resolve(__dirname, 'build')
},
resolve: {
extensions: ['.js', '.jsx']
},
module: {
rules: [
{
test: /\.jsx?$/,
loader: "babel-loader",
options: {
presets: [
"env",
"react"
]
}
},
],
}
};
Here is my package.json file:
{
"name": "react-help-queue",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"react": "^15.5.4",
"react-dom": "^15.5.4"
},
"devDependencies": {
"babel-core": "^6.24.1",
"babel-loader": "^7.0.0",
"babel-preset-env": "^1.6.1",
"babel-preset-react": "^6.24.1",
"webpack": "^3.8.1"
}
}
Huh, it looks like running "webpack" on the command line is invoking a different tool (maybe "webpacker"? https://github.com/rails/webpacker)
There are two ways to solve this:
add a additional script to package.json to kick off webpack.
"scripts": {
"build": "webpack -p"
},
With the above added, execute this command in a terminal: npm run build.
When a script is executed via npm run, npm will automatically include binaries (like webpack) in its PATH, so it the script uses the webpack binary that is part of the apps dev dependencies. Read more on this here: https://docs.npmjs.com/cli/run-script.
Install webpack globally: npm install -g webpack.
This will make webpack available at the command line in all cases, which allows the developer to just type webpack and have it run. This should(?) override the existing "webpacker" command. If not, you may need to uninstall that tool or modify your PATH.
Installing npm packages globally is convienient but it can cause headaches. For example, if two different projects need two different versions of webpack, it may not be efficient. Also, you may find there are several steps in a "build" to execute once an application gets more complex, so having a convenient script included in the project may be appealing (especially for projects with multiple developers).
Hope this helps!
Related
I have 4 packages in my package.json:
"#CT/package-1": "*",
"#CT/package-2": "*",
"#CT/package-3": "*",
"#CT/package-4": "*",
All four packages are not on the NPM registry, but locally linked.
In each package directory I did:
sudo npm link
After that I went into my main project and linked all packages like so:
npm link #CT/package-1
npm link #CT/package-2
npm link #CT/package-3
npm link #CT/package-4
For each command it outputs the linked chain of the sym-links, I checked the paths of each one, and it's correct. If I go in the node_modules folder of my main project and follow #CT/package-X I will end up in my local package directory.
Now I expect that I can run npm i on my main project and it won't try to install those packages from the npm registry. This works for package 2-4, but it does not work for package-1:
npm ERR! code E404
npm ERR! 404 Not Found - GET https://npm.pkg.github.com/#CT%2fpackage-1 - npm package "package-1" does not exist under owner "CT"
As soon as I remove "#CT/package-1": "*", from my package.json, npm i will success, because it seems to right-fully skip package 2-4, just not package-1.
Now I inspected all four package projects, and it makes no sense to me. All projects compile, all package.json contain the correct package name. Here is the package.json of my first faulty package:
{
"name": "#CT/package-1",
"version": "0.0.2",
"description": "",
"main": "dist/plugin.cjs.js",
"module": "dist/esm/index.js",
"types": "dist/esm/index.d.ts",
"unpkg": "dist/plugin.js",
"files": [
"android/src/main/",
"android/build.gradle",
"dist/"
],
"author": "martin-braun",
"license": "ISC",
"keywords": [
"capacitor",
"plugin",
"native"
],
"scripts": {
"lint": "npm run prettier -- --check",
"prettier": "prettier \"**/*.{css,html,ts,js,java}\"",
"build": "npm run prettier && npm run clean && tsc && rollup -c rollup.config.js",
"clean": "rimraf ./dist",
"watch": "tsc --watch",
"prepublishOnly": "npm run build"
},
"devDependencies": {
"#capacitor/android": "^3.0.0",
"#capacitor/core": "^3.0.0",
"#capacitor/docgen": "^0.0.18",
"#ionic/eslint-config": "^0.3.0",
"#ionic/prettier-config": "^1.0.1",
"eslint": "^7.11.0",
"prettier": "~2.2.0",
"prettier-plugin-java": "~1.0.0",
"rimraf": "^3.0.2",
"rollup": "^2.32.0",
"typescript": "~4.0.3"
},
"peerDependencies": {
"#capacitor/core": "^3.0.0"
},
"prettier": "#ionic/prettier-config",
"eslintConfig": {
"extends": "#ionic/eslint-config/recommended"
},
"capacitor": {
"android": {
"src": "android"
}
},
"publishConfig": {
"registry": "https://npm.pkg.github.com/CT"
},
"dependencies": {}
}
.npmrc
registry=https://npm.pkg.github.com/#CT
registry=https://registry.npmjs.org
When I linked the project on my main project it shew the right paths (i.e.)
/Users/mb/Projects/CT/MAIN/node_modules/#CT/package-1 -> /Users/mb/node_module_collections/ekol/lib/node_modules/#CT/package-1 -> /Users/mb/Projects/CT/package-1
What could I try to find the issue? Again, package 2-4 won't cause npm i to fail, but package.json and npmrc look similar. I'm thankful for any advice.
node v13.12.0
When I try to build one of the NextJS apps in my monorepo, I get the error:
$ rm -r packages/library/node_modules/; rm -r packages/daily/node_modules/; rm -r node_modules/; rm -r packages/shared/node_modules; rm package-lock.json; sudo rm -r packages/daily/.next/; npm i; npm --prefix packages/daily/ run build
> next build
info - Using webpack 5. Reason: Enabled by default https://nextjs.org/docs/messages/webpack5
info - Checking validity of types
info - Creating an optimized production build
Failed to compile.
HookWebpackError: processor is not a function
> Build error occurred
Error: > Build failed because of webpack errors
at /home/ubuntu/cal-frontend/packages/daily/node_modules/next/dist/build/index.js:397:19
at async Span.traceAsyncFn (/home/ubuntu/cal-frontend/packages/daily/node_modules/next/dist/telemetry/trace/trace.js:60:20)
at async Object.build [as default] (/home/ubuntu/cal-frontend/packages/daily/node_modules/next/dist/build/index.js:77:25)
The strange thing is that the node/npm version and code are exactly the same as a few days ago when I last ran this command successfully. I have never had this error before. I even tried cloning to a brand new Linux EC2 instance to see if there was some cached file screwing it up but I got exact same error. I am still able to re-deploy the latest commit on Heroku from a few days ago.
The next dev command works fine still.
The issue started happening when I tried to create a new website under packages/ . But the error is persisting even after I reverted to a commit before I made that code.
The monorepo contains two websites that share a package of shared code inside the repo called shared. Here is the webpack next.config.js file for the package/daily app. Again, no code has changed since the error started.
const withFonts = require('next-fonts');
const withTM = require('next-transpile-modules')(['#my-repo-name/shared']);
require('dotenv').config({ path: '../../.env' });
module.exports = withTM(withFonts({
eslint: {
// Warning: This allows production builds to successfully complete even if
// your project has ESLint errors.
ignoreDuringBuilds: true,
},
webpack(config, options) {
return config;
},
}));
node version: v16.10.0
npm version: 7.24.0
(I also tried building using 16.14 and 8.3, and had the same error)
Also the root level package.json (with personal details redacted):
{
"name": "my-repo-name",
"version": "1.0.0",
"workspaces": {
"packages": [
"packages/*"
]
},
"keywords": [],
"author": "redacted-for-stack-overflow#stackoverflow.org",
"license": "UNLICENSED",
"description": "REDACTED FOR STACK OVERFLOW",
"engines": {
"node": "16.10.0"
},
"cacheDirectories": [
"node_modules",
"packages/library/.next/cache"
],
"scripts": {
"lint": "eslint . --ext js,jsx",
"build": "npm run build --prefix packages/$APP_NAME"
},
"dependencies": {},
"devDependencies": {
"babel-eslint": "^10.1.0",
"eslint": "^7.32.0",
"eslint-config-next": "^11.1.2",
"eslint-plugin-import": "^2.24.2",
"eslint-plugin-jsx-a11y": "^6.4.1",
"eslint-plugin-react": "^7.26.1",
"eslint-plugin-react-hooks": "^4.2.0"
}
}
There was an incident yesterday which was causing the issue at Vercel. It should be fixed now.
Adding resolutions keys in package.json solved this for me. Hope this should be a temporary issue with vercel.
"resolutions": {
"cssnano-preset-simple": "3.0.0"
}
I looked at and executed almost every single answer on this post:
The CLI moved into a separate package: webpack-cli
It has not helped.
Allow me to present my case:
So I have developed a container folder, a separate application where I ran npm init -y and then installed the following:
npm install html-webpack-plugin#4.5.0 nodemon webpack#5.3.2 webpack-cli#4.1.0 webpack-dev-server#3.11.0
Then I went into my package.json file and added the start script:
{
"name": "container",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "webpack serve"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"html-webpack-plugin": "^4.5.0",
"nodemon": "^2.0.6",
"webpack": "^5.3.2",
"webpack-cli": "^4.1.0",
"webpack-dev-server": "^3.11.0"
}
}
When I go to terminal and run npm start, this is why I get every single time:
➜ container npm start
> container#1.0.0 start /Users/luiscortes/Projects/ecommRS/container
> webpack serve
[webpack-cli] The command moved into a separate package: #webpack-cli/serve
? Would you like to install #webpack-cli/serve? (That will run npm install -D #webpack-cli/serve) (Y/n) › true
And yes even if I choose Y or true and it runs its npm install -D #webpack-cli/serve, when I go back to running npm start it just gives me the same error over and over again.
Apparently, this is an issue with webpack-cli#4.1.0. I upgraded to webpack-cli#4.2.0 and now it works.
EDIT #1: seems like I have a working configuration, all suggestions to improve this are welcome though. See answer: https://stackoverflow.com/a/42269408/1155847
ORIGINAL QUESTION:
I'm currently trying to setup my environment so that my package.json's devDependencies typescript version will be used. What are some of the best practices for this, so that it is "editor unaware" and preferably can be used as an npm script, e.g.: npm run tscompile?
To be clear - I can get everything working when using npm install typescript -g - but then I'm relying on a global installed version, whic is not what I want - as we'll want to work in a team and set on a specific typescript version for each member before upgrading, so we're all on the same page.
I'm currently trying to set it up like this - yet npm then complains it doesn't recognize "node_modules" as an internal or external command... I presume I do have to pass the tsconfig.json to tsc as well, or at least give it the "working directory" - but I can't even get past launching tsc from my locally downloaded npm cache.
package.json
{
"name": "tswithnodejsgettingstarted",
"version": "1.0.0",
"description": "",
"main": "app/index.js",
"scripts": {
"start": "node app/index.js",
"tscompile": "node_modules/typescript/tsc"
},
"author": "",
"license": "ISC",
"devDependencies": {
"typescript": "2.1.6"
}
}
tsconfig.json
{
"compileOnSave": true,
"compilerOptions": {
"module": "commonjs",
"noImplicitAny": true,
"sourceMap": true,
"outDir": "app"
},
"include": [
"src/**/*.ts"
],
"exclude": [
"node_modules"
]
}
Ok... It seems like it was as simple as this (see below). Answering it here, for anyone else looking for the answer. Or please let me know if there are better solutions.
Configure the script like "tsc": "tsc" inside package.json. Then just run npm run tsc and it will use your tsc version you have installed locally, and discover your tsconfig.json of course. It doesn't use your global version - as I uninstalled that one - just entering tsc in the command line errors out.
E.g.:
Check the repo* where I was playing with this.
package.json
{
"name": "tscnodejsgettingstarted",
"version": "1.0.0",
"description": "",
"main": "app/index.js",
"scripts": {
"start": "npm run tsc && node app/index.js",
"tsc": "tsc"
},
"author": "",
"license": "ISC",
"devDependencies": {
"typescript": "2.1.6"
}
}
*repo: https://github.com/pluralsight-courses/typescript-fundamentals/tree/master/001-GettingStarted
You can also use the prestart script. By default it runs before the start command (see all the default scripts that you can set up here).
"scripts": {
"prestart": "npm run tsc",
"start": "node app/index.js",
"tsc": "tsc"
}
I have an npm module my_lib that is providing some objects I would like available for use by several downstream modules. my_lib is written in ES6, and uses babel to transpile. It lives in a private github repo accessible to the building hosts of the downstream modules. It is important that the downstream modules consuming my_lib are able to import symbols from my_lib like any other node module.
I would like to be able to write import { libA, libB } from 'my_lib'; in any of the downstream modules and have libA defined as expected by my_lib, assuming that downstream module's package.json includes in dependencies an entry like "my_lib": "orgname/reponame#branchname"
I have an entry in my_lib package.json under scripts like so :
"postinstall" : "npm run build",
"build": "mkdir ./dist && browserify ./src/index.js -t babelify -t envify -o index.js",`
where ./src/index.js is
// Entry point for bundling
export * as libB from "../sublib1/adapter";
export * as libA from "../sublib2/adapter";
If necessary, I could call import {libA, libB} from my_lib/dist/bundle, though this is somewhat undesirable. The main thing is to make all the names I'm exporting from my_lib available in the downstream modules. I'm probably confused about what's going on with browserify and babel. I'm perfectly happy to change the postinstall/build hooks to whatever form is more convenient.
Currently, in the downstream package (an express.js app), I have the line import * as adapters from my_lib; Running npm install on the express app completes without error. I see the index.js file I expect in node_modules/my_lib. When I break in my app after the import (or require for that matter), the adapters object exists, but none of the libB or libA on the object. It seems to be a pure vanilla JS object with no members but __proto__.
Normally in this case i will just use babel and avoid browserify. I use something like this in package.json:
{
"main": "dist/index.js",
"scripts": {
"postinstall": "babel src/ -d dist/"
},
"dependencies": {
"babel-cli": "^6.9.0",
"babel-preset-es2015": "^6.9.0"
}
}
Notice that the main entry point for the package is pointing to dist and not to src. This is to make import my_lib and require('my_lib') (both work well) to use the compiled version of the library.
Additionally this is the content of the .babelrc file that it is side by side with package.json
{
"presets": ["es2015"]
}
I use babel and browserify together.
My package.json
{
"name": "my-project",
"version": "1.0.0",
"scripts": {
"build:js": "watchify assets/src/js/main_1.js -o 'exorcist assets/dist/js/main_1.js.map > assets/dist/js/main_1.js' -d -t [babelify --presets [latest]]",
"build:scss": "node-sass -w -r assets/src/scss/ -o assets/dist/css/",
"build": "npm run build:scss & npm run build:js"
},
"devDependencies": {
"babel-cli": "^6.0.0",
"babel-preset-latest": "^6.16.0",
"babelify": "^7.3.0",
"browserify": "^13.1.1",
"exorcist": "^0.4.0",
"node-sass": "^4.5.0",
"watchify": "^3.7.0"
},
"browserify": {
"transform": [
"babelify"
]
}
}
Actual version of package.json: https://gist.github.com/artamonovdev/5f24aaca504e4d1b299bba0413f0a57d