How can I configure metro to resolve modules outside of my project directory? - react-native

For reasons that are out of my control, I need to resolve a module that is outside of my react-native project directory. So, consider the following directory structure:
react-native-project/
├─ App.jsx
├─ babel.config.js
external-directory/
├─ Foo.jsx
I would like any import Foo from 'Foo' inside of react-native-project to resolve ../external-directory/Foo.jsx. My first attempt at this was to use babel-plugin-module-loader with the following configuration:
plugins: [
[
'module-resolver',
{
alias: {
Foo: '/absolute/path/to/external-directory/Foo',
},
},
],
],
This doesn't work, with metro emitting the following error:
error: Error: Unable to resolve module /absolute/path/to/external-directory/Foo from /absolute/path/to/react-native-project/App.jsx:
None of these files exist:
* ../external-directory/Foo(.native|.ios.js|.native.js|.js|.ios.jsx|.native.jsx|.jsx|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
* ../external-directory/Foo/index(.native|.ios.js|.native.js|.js|.ios.jsx|.native.jsx|.jsx|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
This error message is wrong: ../external-directory/Foo.jsx does exist. I've verified this numerous times. I've also set up a standalone babel package to test an identical import scenario, and babel correctly resolves the external module.
The other approach I took was to add a custom resolveRequest function in my metro.config.js:
const defaultResolver = require('metro-resolver').resolve;
module.exports = {
...
resolver: {
resolveRequest: (context, moduleName, platform, realModuleName) => {
if (moduleName === 'Foo') {
return {
filePath: '/absolute/path/to/external-directory/Foo.jsx',
type: 'sourceFile',
};
} else {
return defaultResolver(
{
...context,
resolveRequest: null,
},
moduleName,
platform,
realModuleName,
);
}
},
},
};
This also doesn't work, emitting the following error message:
error: ReferenceError: SHA-1 for file /absolute/path/to/external-directory/Foo.jsx (/absolute/path/to/external-directory/Foo.jsx) is not computed.
Potential causes:
1) You have symlinks in your project - watchman does not follow symlinks.
2) Check `blockList` in your metro.config.js and make sure it isn't excluding the file path.
The potential causes do not apply in this scenario: There are no symlinks nor does the blockList contain the external directory (I explicitly configured blockList: null to verify).
Is there any way to accomplish what I'm trying to do? Or does metro (either by design or incidentally) prevent this?

You can use a metro bundler build in option - extraNodeModules and watchFolders.
const path = require('path');
module.exports = {
resolver: {
...,
extraNodeModules: {
app: path.resolve(__dirname + '/../app')
}
},
...,
watchFolders: [
path.resolve(__dirname + '/../app')
]
};

Related

how to use react-monaco-editor together with worker-loader?

Describe the bug
react-monaco-editor cannot be used together with worker-loader.
To Reproduce
create a new typescript app with CRA, run a min react-monaco-editor demo. (everything is fine)
install worker loader and add config in config-overrides.js, and start app.
example repo to reproduce
ERROR in ./node_modules/monaco-editor/esm/vs/editor/editor.worker.js
Module build failed (from ./node_modules/worker-loader/dist/cjs.js):
TypeError: Cannot read properties of undefined (reading 'replace')
at getDefaultChunkFilename (/Users//Documents/test/my-project/node_modules/worker-loader/dist/utils.js:23:24)
at Object.pitch (/Users//Documents/test/my-project/node_modules/worker-loader/dist/index.js:61:108)
Child vs/editor/editor compiled with 1 error
assets by status 1.27 KiB [cached] 1 asset
./node_modules/monaco-editor/esm/vs/language/json/json.worker.js 39 bytes [not cacheable] [built] [1 error]
ERROR in ./node_modules/monaco-editor/esm/vs/language/json/json.worker.js
Module build failed (from ./node_modules/worker-loader/dist/cjs.js):
TypeError: Cannot read properties of undefined (reading 'replace')
at getDefaultChunkFilename (/Users//Documents/test/my-project/node_modules/worker-loader/dist/utils.js:23:24)
at Object.pitch (/Users//Documents/test/my-project/node_modules/worker-loader/dist/index.js:61:108)
Child vs/language/json/jsonWorker compiled with 1 error
details of my config-overrides.js
const webpack = require('webpack');
const MonacoWebpackPlugin = require('monaco-editor-webpack-plugin');
module.exports = function override(config, env) {
config.plugins.push(
new MonacoWebpackPlugin({
languages: ['json']
})
);
config.stats = {
children: true
}
config.module.rules.push(
{
test: /\.worker\.js$/,
use: {
loader: 'worker-loader',
options: {
inline: 'fallback',
filename: '[contenthash].worker.js',
},
},
},
{
test: /\.worker\.ts$/,
use: [
{
loader: 'worker-loader',
options: {
inline: 'fallback',
filename: '[contenthash].worker.js',
},
},
'ts-loader',
],
},
);
return config;
};
Environment (please complete the following information):
OS: MacOS
Browser Chrome
Bundler webpack5 (CRA)
[ ] I will try to send a pull request to fix this issue.
I have solved it. It seems not to be a problem of react-monaco-editor or monaco-editor.
The problem is between worker-loader and monaco-editor-webpack-plugin.
I temporarily update my worker-loader config to match workers in my src folder only and solve this problem.
It could be better to figure out how to configure it in monaco-editor-webpack-plugin because it build files contains worker from monaco-editor without hashcode.

The debugger adapter not works after vsce package

I developed a debug extension which uses an external js debugger adapter. I put the js file to the bin directory looks like this.
rootDir
--bin
----adapter.js
And I used it like this in my development environment.
{
"label": "ThingIO Debugger",
"program": "./bin/adapter.js",
"runtime": "node",
"type": "thingio-debug"
}
The code works well in my development mode, but when I packaged it to a .vsix file and install to another machine, it failed immediately.
The webpack file is below
//#ts-check
'use strict';
const path = require('path');
//#ts-check
/** #typedef {import('webpack').Configuration} WebpackConfig **/
/** #type WebpackConfig */
const extensionConfig = {
target: 'node', // vscode extensions run in a Node.js-context 📖 -> https://webpack.js.org/configuration/node/
mode: 'none', // this leaves the source code as close as possible to the original (when packaging we set this to 'production')
entry: './src/extension.ts', // the entry point of this extension, 📖 -> https://webpack.js.org/configuration/entry-context/
output: {
// the bundle is stored in the 'dist' folder (check package.json), 📖 -> https://webpack.js.org/configuration/output/
path: path.resolve(__dirname, 'dist'),
filename: 'extension.js',
libraryTarget: 'commonjs2'
},
externals: {
vscode: 'commonjs vscode' // the vscode-module is created on-the-fly and must be excluded. Add other modules that cannot be webpack'ed, 📖 -> https://webpack.js.org/configuration/externals/
// modules added here also need to be added in the .vscodeignore file
},
resolve: {
// support reading TypeScript and JavaScript files, 📖 -> https://github.com/TypeStrong/ts-loader
extensions: ['.ts', '.js']
},
module: {
rules: [
{
test: /\.ts$/,
exclude: /node_modules/,
use: [
{
loader: 'ts-loader'
}
]
}
]
},
devtool: 'nosources-source-map',
infrastructureLogging: {
level: "log", // enables logging required for problem matchers
},
};
module.exports = [ extensionConfig ];
And the vscode:prepublish command is webpack --mode production --devtool hidden-source-map
I think it looks like the debugger adapter program is not found. So I checked the ~/.vscode/extensions, and the adapter js file exists in the right path.
Now I'm very confused about what wrong is with the extension. Maybe the path is wrong or the webpack did not compile the right file in some situation?
Can anyone give some solution or suggestion about this?

Next.js: Jest encountered an unexpected token. Jest failed to parse a file. Crashing due to dot ( .{color: red} ) before a className in CSS files [duplicate]

I am trying to get my first Jest Test to pass with React and Babel.
I am getting the following error:
SyntaxError: /Users/manueldupont/test/avid-sibelius-publishing-viewer/src/components/TransportButton/TransportButton.less: Unexpected token
> 7 | #import '../variables.css';
| ^
My package.json config for jest look like this:
"babel": {
"presets": [
"es2015",
"react"
],
"plugins": [
"syntax-class-properties",
"transform-class-properties"
]
},
"jest": {
"moduleNameMapper": {
"^image![a-zA-Z0-9$_-]+$": "GlobalImageStub",
"^[./a-zA-Z0-9$_-]+\\.png$": "RelativeImageStub"
},
"testPathIgnorePatterns": [
"/node_modules/"
],
"collectCoverage": true,
"verbose": true,
"modulePathIgnorePatterns": [
"rpmbuild"
],
"unmockedModulePathPatterns": [
"<rootDir>/node_modules/react/",
"<rootDir>/node_modules/react-dom/",
"<rootDir>/node_modules/react-addons-test-utils/",
"<rootDir>/node_modules/fbjs",
"<rootDir>/node_modules/core-js"
]
},
So what am I missing?
moduleNameMapper is the setting that tells Jest how to interpret files with different extension. You need to tell it how to handle Less files.
Create a file like this in your project (you can use a different name or path if you’d like):
config/CSSStub.js
module.exports = {};
This stub is the module we will tell Jest to use instead of CSS or Less files. Then change moduleNameMapper setting and add this line to its object to use it:
'^.+\\.(css|less)$': '<rootDir>/config/CSSStub.js'
Now Jest will treat any CSS or Less file as a module exporting an empty object. You can do something else too—for example, if you use CSS Modules, you can use a Proxy so every import returns the imported property name.
Read more in this guide.
I solved this by using the moduleNameMapper key in the jest configurations in the package.json file
{
"jest":{
"moduleNameMapper":{
"\\.(css|less|sass|scss)$": "<rootDir>/__mocks__/styleMock.js",
"\\.(gif|ttf|eot|svg)$": "<rootDir>/__mocks__/fileMock.js"
}
}
}
After this you will need to create the two files as described below
__mocks__/styleMock.js
module.exports = {};
__mocks__/fileMock.js
module.exports = 'test-file-stub';
If you are using CSS Modules then it's better to mock a proxy to enable className lookups.
hence your configurations will change to:
{
"jest":{
"moduleNameMapper": {
"\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js",
"\\.(css|less|scss|sass)$": "identity-obj-proxy"
},
}
}
But you will need to install identity-obj-proxy package as a dev dependancy i.e.
yarn add identity-obj-proxy -D
For more information. You can refer to the jest docs
UPDATE who use create-react-app from feb 2018.
You cannot override the moduleNameMapper in package.json but in jest.config.js it works, unfortunately i havent found any docs about this why it does.
So my jest.config.js look like this:
module.exports = {
...,
"moduleNameMapper": {
"\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js",
"\\.(scss|sass|css)$": "identity-obj-proxy"
}
}
and it skips scss files and #import quite well.
Backing my answer i followed jest webpack
Similar situation, installing identity-object-proxy and adding it to my jest config for CSS is what worked for me.
//jest.config.js
module.exports = {
moduleNameMapper: {
"\\.(css|sass)$": "identity-obj-proxy",
},
};
The specific error I was seeing:
Jest encountered an unexpected token
/Users/foo/projects/crepl/components/atoms/button/styles.css:1
({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){.button { }
^
SyntaxError: Unexpected token .
1 | import React from 'react';
> 2 | import styles from './styles.css';
If you're using ts-jest, none of the solutions above will work! You'll need to mock transform.
jest.config.js
module.exports = {
preset: 'ts-jest',
testEnvironment: 'jsdom',
roots: [
"<rootDir>/src"
],
transform: {
".(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/jest-config/file-mock.js",
'.(css|less)$': '<rootDir>/jest-config/style-mock.js'
},
};
file-mock.js
module.exports = {
process() {
return `module.exports = 'test-file-stub'`;
},
};
style-mock.js
module.exports = {
process() {
return 'module.exports = {};';
}
};
I found this working example if you want more details.
Solution of #import Unexpected token=:)
Install package:
npm i --save-dev identity-obj-proxy
Add in jest.config.js
module.exports = {
"moduleNameMapper": {
"\\.(css|less|scss)$": "identity-obj-proxy"
}
}
Update: Aug 2021
If you are using Next JS with TypeScript. Simply follow the examples repo.
Else you will be wasting days configuring the environment.
https://github.com/vercel/next.js/tree/canary/examples/with-jest
I added moduleNameMapper at the bottom of my package.json where I configured my jest just like this:
"jest": {
"verbose": true,
"moduleNameMapper": {
"\\.(scss|less)$": "<rootDir>/config/CSSStub.js"
}
}

VueJS build started throwing Error: Conflict: Multiple assets emit to the same filename

My app used to work fine until I updated VueJS this morning. Now when I build, it shows the following error:
Error: Conflict: Multiple assets emit to the same filename img/default-contractor-logo.0346290f.svg
There's only one file like this in the repo.
Here's my vue.config.js:
module.exports = {
baseUrl: '/my/',
outputDir: 'dist/my',
css: {
loaderOptions: {
sass: {
data: `
#import "#/scss/_variables.scss";
#import "#/scss/_mixins.scss";
#import "#/scss/_fonts.scss";
`
}
}
},
devServer: {
disableHostCheck: true
}
};
I tried webpack fixes recommended in similar cases, but non helped.
I had the same error when importing SVG files using dynamically generated path in the require statement:
const url = require("../assets/svg/#{value}");
<img src={{url}} />
In this case file-loader processes all SVG files and saves them to the output path. My file-loader options were:
{
loader: "file-loader",
options: { name: "[name].[ext]" }
}
The folders structure has duplicate file names, something like this:
assets
|__ one
|____ file.svg
|__ two
|____ file.svg
In this case file-loader saves both file.svg files to the same output file: build/assets/file.svg - hence the warning.
I managed to fix it by adding [path] to the name option:
{
loader: "file-loader",
options: { name: "[path][name].[ext]" }
}
The answer by #ischenkodv is definitely correct, but because of my inexperience with webpack, I needed a little more context to use the information to fix the problem.
For the benefit of anyone else in the same situation, I'm adding the following details which I hope will be useful.
This section of the Vue.js documentation was particularly helpul:
VueJS - Modifying Options of a Loader
For the TL;DR fix, here is the relevant chunk of my vue.config.js:
// vue.config.js
module.exports = {
// ---snip---
chainWebpack: config =>
{
config.module
.rule('svg')
.test(/\.svg$/)
.use('file-loader')
.tap(options =>
{
return { name: "[path][name].[ext]" };
});
}
// ---snip---
};
In my project it was the flag-icon-css NPM package that was causing the Multiple assets emit to the same filename conflict errors. The above update to the vue.config.js file resolved the problem for me.
I suspect that the regular expression in the test could be tightened up to target just the items in the flag-icon-css package rather than matching all SVG files, but I haven't bothered since it's not causing any adverse effects so far.

Field 'browser' doesn't contain a valid alias configuration

I've started using webpack2 (to be precise, v2.3.2) and after re-creating my config I keep running into an issue I can't seem to solve I get (sorry in advance for ugly dump):
ERROR in ./src/main.js
Module not found: Error: Can't resolve 'components/DoISuportIt' in '[absolute path to my repo]/src'
resolve 'components/DoISuportIt' in '[absolute path to my repo]/src'
Parsed request is a module
using description file: [absolute path to my repo]/package.json (relative path: ./src)
Field 'browser' doesn't contain a valid alias configuration
aliased with mapping 'components': '[absolute path to my repo]/src/components' to '[absolute path to my repo]/src/components/DoISuportIt'
using description file: [absolute path to my repo]/package.json (relative path: ./src)
Field 'browser' doesn't contain a valid alias configuration
after using description file: [absolute path to my repo]/package.json (relative path: ./src)
using description file: [absolute path to my repo]/package.json (relative path: ./src/components/DoISuportIt)
as directory
[absolute path to my repo]/src/components/DoISuportIt doesn't exist
no extension
Field 'browser' doesn't contain a valid alias configuration
[absolute path to my repo]/src/components/DoISuportIt doesn't exist
.js
Field 'browser' doesn't contain a valid alias configuration
[absolute path to my repo]/src/components/DoISuportIt.js doesn't exist
.jsx
Field 'browser' doesn't contain a valid alias configuration
[absolute path to my repo]/src/components/DoISuportIt.jsx doesn't exist
[[absolute path to my repo]/src/components/DoISuportIt]
[[absolute path to my repo]/src/components/DoISuportIt]
[[absolute path to my repo]/src/components/DoISuportIt.js]
[[absolute path to my repo]/src/components/DoISuportIt.jsx]
package.json
{
"version": "1.0.0",
"main": "./src/main.js",
"scripts": {
"build": "webpack --progress --display-error-details"
},
"devDependencies": {
...
},
"dependencies": {
...
}
}
In terms of the browser field it's complaining about, the documentation I've been able to find on this is: package-browser-field-spec. There is also webpack documentation for it, but it seems to have it turned on by default: aliasFields: ["browser"]. I tried adding a browser field to my package.json but that didn't seem to do any good.
webpack.config.js
import path from 'path';
const source = path.resolve(__dirname, 'src');
export default {
context: __dirname,
entry: './src/main.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].js',
},
resolve: {
alias: {
components: path.resolve(__dirname, 'src/components'),
},
extensions: ['.js', '.jsx'],
},
module: {
rules: [
{
test: /\.(js|jsx)$/,
include: source,
use: {
loader: 'babel-loader',
query: {
cacheDirectory: true,
},
},
},
{
test: /\.css$/,
include: source,
use: [
{ loader: 'style-loader' },
{
loader: 'css-loader',
query: {
importLoader: 1,
localIdentName: '[path]___[name]__[local]___[hash:base64:5]',
modules: true,
},
},
],
},
],
},
};
src/main.js
import DoISuportIt from 'components/DoISuportIt';
src/components/DoISuportIt/index.jsx
export default function() { ... }
For completeness, .babelrc
{
"presets": [
"latest",
"react"
],
"plugins": [
"react-css-modules"
],
"env": {
"production": {
"compact": true,
"comments": false,
"minified": true
}
},
"sourceMaps": true
}
What am I doing wrong/missing?
Turned out to be an issue with Webpack just not resolving an import - talk about horrible horrible error messages :(
// I Had to change:
import DoISuportIt from 'components/DoISuportIt';
// to (notice the missing `./`)
import DoISuportIt from './components/DoISuportIt';
Just for record, because I had similiar problem, and maybe this answer will help someone: in my case I was using library which was using .js files and I didn't had such extension in webpack resolve extensions. Adding proper extension fixed problem:
module.exports = {
(...)
resolve: {
extensions: ['.ts', '.js'],
}
}
I'm building a React server-side renderer and found this can also occur when building a separate server config from scratch. If you're seeing this error, try the following:
Make sure your entry value is properly pathed relative to your context value. Mine was missing the preceeding ./ before the entry file name.
Make sure you have your resolve value included. Your imports on anything in node_modules will default to looking in your context folder, otherwise.
Example:
const serverConfig = {
name: 'server',
context: path.join(__dirname, 'src'),
entry: {serverEntry: ['./server-entry.js']},
output: {
path: path.join(__dirname, 'public'),
filename: 'server.js',
publicPath: 'public/',
libraryTarget: 'commonjs2'
},
module: {
rules: [/*...*/]
},
resolveLoader: {
modules: [
path.join(__dirname, 'node_modules')
]
},
resolve: {
modules: [
path.join(__dirname, 'node_modules')
]
}
};
I encountered this error in a TypeScript project. In my webpack.config.js file I was only resolving TypeScript files i.e.
resolve: {
extensions: [".ts"],
}
However I noticed that the node_module which was causing the error:
Field 'browser' doesn't contain a valid alias configuration
did not have any ".ts" files (which is understandable as the module has been converted to vanilla JS. Doh!).
So to fix the issue I updated the resolve declaration to:
resolve: {
extensions: [".ts", ".js"],
}
I had the same issue, but mine was because of wrong casing in path:
// Wrong - uppercase C in /pathCoordinate/
./path/pathCoordinate/pathCoordinateForm.component
// Correct - lowercase c in /pathcoordinate/
./path/pathcoordinate/pathCoordinateForm.component
Add this to your package.json:
"browser": {
"[module-name]": false
},
Changed my entry to
entry: path.resolve(__dirname, './src/js/index.js'),
and it worked.
This also occurs when the webpack.config.js is simply missing (dockerignore 🤦‍♂️)
In my case it was a package that was installed as a dependency in package.json with a relative path like this:
"dependencies": {
...
"phoenix_html": "file:../deps/phoenix_html"
},
and imported in js/app.js with import "phoenix_html"
This had worked but after an update of node, npm, etc... it failed with the above error-message.
Changing the import line to import "../../deps/phoenix_html" fixed it.
My case was rather embarrassing: I added a typescript binding for a JS library without adding the library itself.
So if you do:
npm install --save #types/lucene
Don't forget to do:
npm install --save lucene
Kinda obvious, but I just totally forgot and that cost me quite some time.
In my case, to the very end of the webpack.config.js, where I should exports the config, there was a typo: export(should be exports), which led to failure with loading webpack.config.js at all.
const path = require('path');
const config = {
mode: 'development',
entry: "./lib/components/Index.js",
output: {
path: path.resolve(__dirname, 'public'),
filename: 'bundle.js'
},
module: {
rules: [
{
test: /\.js$/,
loader: 'babel-loader',
exclude: path.resolve(__dirname, "node_modules")
}
]
}
}
// pay attention to "export!s!" here
module.exports = config;
I had aliases into tsconfig.json:
{
"compilerOptions": {
"paths": {
"#store/*": ["./src/store/*"]
}
},
}
So I solved this issue by adding aliases to webpack.config also:
module.exports = {
//...
resolve: {
alias: {
'#store': path.resolve(__dirname, '../src/store'),
},
},
};
I got same problem and fixed with adding file extension.
// Old:
import RadioInput from './components/RadioInput'
// New:
import RadioInput from './components/RadioInput.vue'
Also, if you still want to use without extensions, you can add this webpack config: (Thanx for #matthew-herbst for the info)
module.exports = {
//...
resolve: {
extensions: ['.js', '.json', '.wasm'], // Add your extensions here.
},
};
For anyone building an ionic app and trying to upload it. Make sure you added at least one platform to the app. Otherwise you will get this error.
In my experience, this error was as a result of improper naming of aliases in Webpack.
In that I had an alias named redux and webpack tried looking for the redux that comes with the redux package in my alias path.
To fix this, I had to rename the alias to something different like Redux.
In my case, it was due to a broken symlink when trying to npm link a custom angular library to consuming app. After running npm link #authoring/canvas
"#authoring/canvas": "path/to/ui-authoring-canvas/dist"
It appear everything was OK but the module still couldn't be found:
When I corrected the import statement to something that the editor could find Link:
import {CirclePackComponent} from '#authoring/canvas/lib/circle-pack/circle-pack.component';
I received this which is mention in the overflow thread:
To fix this I had to:
cd /usr/local/lib/node_modules/packageName
cd ..
rm -rf packageName
In the root directory of the library, run:
a) rm -rf dist
b) npm run build
c) cd dist
d) npm link
In the consuming app, update the package.json with:
"packageName": "file:/path/to/local/node_module/packageName""
In the root directory of the consuming app run npm link packageName
In my case (lolz),
I was importing a local package (that I was developing, and building with rollup) via NPM/Yarn link, into another package I was developing. The imported package was a load of React components, and was configured to have a peerDependency of react and react-dom.
The consuming package was being built with Webpack and obviously wasn't correctly feeding the installed react and react-dom libraries into my local dependency as it was compiling it.
I adjusted my webpack configuration to indicate it should alias those peer dependencies to the correct dependencies in the consuming package:
/* ... */
resolve: {
extensions: [/* make sure you have them all correct here, as per other answers */],
alias: {
react: path.resolve('./node_modules/react'),
'react-dom': path.resolve('./node_modules/react-dom')
}
},
/* ... */
Obviously you need to import path in the webpack.config.js file in order to use the methods seen above.
A more detailed explanation can be found in this article
My case was similar to #witheng's answer.
At some point, I noticed some casing error in some file names in my development environment. For example the file name was
type.ts
and I renamed it to
Type.ts
In my Mac dev environment this didn't register as a change in git so this change didn't go to source control.
In the Linux-based build machine where the filenames are case-sensitive it wasn't able to find the file with different casing.
To avoid issues like this in the future, I ran this command in the repo:
git config core.ignorecase false
In my case, I imported library files like:
import { MyFile } from "my-library/public-api";
After I removed the public-api from the import everything worked fine:
import { MyFile } from "my-library";
MyFile is exported in the public-api file in the library.
In my case,
I have mistakenly removed a library ("mini-create-react-context") from package.json. I added that back, and did yarn install and build the app and it start working properly. So please take a look at your package.json file once.
In my case I had accidentally imported this package while trying to use process.env:
import * as process from 'process';
Removing it fixed the problem.
For everyone with Ionic:
Updating to the latest #ionic/app-scripts version gave a better error message.
npm install #ionic/app-scripts#latest --save-dev
It was a wrong path for styleUrls in a component to a non-existing file.
Strangely it gave no error in development.
In my situation, I did not have an export at the bottom of my webpack.config.js file. Simply adding
export default Config;
solved it.
In my case, it is due to a case-sensitivity typo in import path. For example,
Should be:
import Dashboard from './Dashboard/dashboard';
Instead of:
import Dashboard from './Dashboard/Dashboard';
In my case I was using invalid templateUrl.By correcting it problem solved.
#Component({
selector: 'app-edit-feather-object',
templateUrl: ''
})
I am using single-spa, and encountered this issue with the error
Module not found: Error: Can't resolve '/builds/**/**/src\main.single-spa.ts' in /builds/**/**'
I eventually figured out that in angular.json build options "main" was set to src\\main.single-spa.ts. Changing it to src/main.single-spa.ts fixed it.
Had the same issue with angular was importing
import { Injectable } from "#angular/core/core";
changed it to
import { Injectable } from "#angular/core";
I was getting this error when running a GitHub action. The issue was because I'd listed the package as a peer dependency instead of a dependency.
Since I'm using Rollup, the solution was to install the package both as a peer dependency and a dev dependency, and use rollup-plugin-peer-deps-external to remove the dev dependency from the final build.
For me the issue was, I was importing
.ts files into .js files
changing them to ts as well solved the issue.
In my case, I had a mixture of enum and interface in the index.d.ts file.
I extracted enums into another file and the issue resolved.