I'm working on converting an existing app to using JSPM. I really appreciate using paths relative to the baseUrl so I don't have to do this ../../../../vendor/... nonsense but I did like being able to import from ./siblingModule to import from something in the same part of the hierarchy. When trying to use jspm bundle that does currently use relative imports I get
Error: ENOENT: no such file or directory, open '<project path + baseUrl>\siblingModule.js'
at Error (native)
Is there a way to configure JSPM to use relative paths for module resolution alongside baseUrl resolution?
Ideally -
module/submodule checks for any valid paths entries and then checks baseUrl/module/submodule
./module/submodule checks in currentPath/module/submodule
/module/submodule checks in baseUrl/module/submodule
As far as I can tell this isn't ambiguous, though please correct me if I'm wrong.
p.s. using jspm 0.16.45
The baseUrl is used to resolve paths.
You can configure mapping and paths in config.json, to import from these paths.
But nothing prevents you to use these kind of import:
import module from './otherModule/file.js';
If you have a problem using import, it is probably something wrong in your configuration.
See documentation: https://github.com/systemjs/systemjs/blob/master/docs/getting-started.md
Related
Hi everyone :) I was hoping I could get some fresh eyes on a problem I'm running into on my project:
I have a NextJS (12.1.4) project using absolute imports, I also have an NPM package where I directly import the source files in my project (since it's a library for shared components, internal use only). This package is called bs-components here.
Here is my jsconfig.json file
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"#bscom/*": ["node_modules/#company/bs-components/*"],
"*": ["node_modules/#company/bs-components/*", "*"]
}
}
}
I will explain the intent behind my paths config here:
The first entry for #bscom/* will allow me to import modules from my library using a shorthand.
The second entry for * is intended so that the module resolution goes like this:
Look in the component library first for a module, so that absolute imports in the component library are respected.
If module is not found in the library, then resolve using the baseUrl as the starting point for resolution.
Unfortunately when using this config, absolute imports within the component library fail with the following error:
./node_modules/#company/bs-components/styling/resets.js:1:0
Module not found: Can't resolve 'constants/colors'
This happens in my NextJS _document.js file, so during the server render step.
There are no modules with that path in my main project which could cause a conflict.
Any suggestions would be greatly appreciated, thanks :)
I've got a Next.js project configured to resolve imports that end in .web.js. This works outside of my node_modules directory. I did this by setting resolve.extensions = ['.web.js, '.js', '.jsx'] in my webpack config. I understand that this setting is responsible for resolving imports that don't have an extension, e.g. import _ from './component', when ./component.web.js exists.
I also have some node_modules that make use of this .web.js extension. They're private modules, but the idea stands. Let's say our node_modules looks like this. It may be worth noting that these modules have already been transpiled and as such use require rather than import.
- node_modules
- #foo
- bar.js
- baz.web.js
- baz.native.js
Now let's say that we have the following:
// bar.js
require("./baz");
If I try to import #foo/bar, the app will throw a module not found error on the line require("./baz"); saying that it can't be found. If I change it to require("./baz.web.js") or remove the line altogether then the app runs fine.
Why can webpack make these kind of resolutions outside of node_modules, but not within the directory? And how can I tell webpack to resolve those imports, too?
Depending on your module resolution strategy, you'll either find some files or not. Node.js resolves modules as outlined here. This means for you that require('./baz') is resolved to requesting /path/to/module/baz.js. Since your file is not actually named, it is not found. You can use require('./baz.web') instead.
As to whether Webpack can "automatically" handle which import to use, it probably comes down to using a plugin or having some sort of logic in bar.js to choose between baz.web and baz.native.
Although I am able to start the npm project using npm start without any issues with webpack or babel, once I run npm test, I find the following error related to testing App.js using App.test.js (where App.js imports ApolloClient):
TypeError: Cannot assign to read only property '__esModule' of object '[object Object]'
| import ApolloClient from 'apollo-boost';
| ^
at node_modules/apollo-boost/lib/bundle.cjs.js:127:74
at Array.forEach (<anonymous>)
at Object.<anonymous> (node_modules/apollo-boost/lib/bundle.cjs.js:127:36)
Essentially, I'm confused as to why I get an error when running the test but not when starting the project.
I've tried adding in a number of babel plugins to both .babelrc and in my webpack config file:
#babel/plugin-transform-object-assign
#babel/plugin-transform-modules-commonjs
babel-plugin-transform-es2015-modules-commonjs
However, I haven't been able to resolve the issue. My thinking was that this is related to the fact that the file that fails to compile was originally CommonJS.
I was only able to find something relatively similar here, https://github.com/ReactTraining/react-router/pull/6758, but I didn't find a solution.
Is there something that I'm missing specifically related to running tests? I should also mention I've tried frameworks other than Jest and ran into the same issue.
EDIT:
I removed everything from App.test.js except the imports to isolate the issue so it just contains the following:
import React from 'react';
import { shallow } from 'enzyme/build';
import App from './App';
UPDATE:
I was able to resolve the initial error by upgrading apollo-boost from version 0.3.1 to 0.4.2. However, I now have a different error that is similarly frustrating. I am using Babel 7 and have added the plugin #babel/plugin-syntax-dynamic-import to both my .babelrc and to my webpack.config.js files. Despite this, I get the following error related to the use of a dynamic import in App.js when running the Jest to test App.test.js:
SyntaxError: Support for the experimental syntax 'dynamicImport' isn't currently enabled
Add #babel/plugin-syntax-dynamic-import (https://git.io/vb4Sv) to the 'plugins' section of your Babel config to enable parsing.
I'm not sure if there is a parsing error or something else, but I've tried numerous things that have not worked. The closest discussion I could find related to this problem is, https://github.com/facebook/jest/issues/5920, however, the proposed solutions don't work for me.
UPDATE:
One thing that I'm trying is to avoid duplication of the babel options as right now they're both in .babelrc and in the babel-loader options within webpack.config.js. From what I found online (Whats the difference when configuring webpack babel-loader vs configuring it within package.json?), the way to make webpack use the settings in .babelrc is to not specify options. However, doing so results in the same error described above showing up only this time when running npm start. I will add that the project that was originally created using create-react-app, however, in order to support multiple pages, I needed to customize webpack's configuration and so ejected from it. I'm not sure why this is so convoluted.
its probably a babel configuration issue, I'm pretty sure jest needs to be compiled to work with create-react-app...
did you specify a setup file in package.json:
"jest": {
"setupFiles": [
"/setupTests.js"
]
}
and in setupTests.js:
import { configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';
configure({ adapter: new Adapter() });
It turns out that one of the components in the project's src directory had its own local package.json file even though it wasn't being used and was not installed as a local dependency in the top level package.json (instead imports were done using relative urls). For some reason, the existence of this file changed the behavior of webpack and other tools when starting and testing the project such that none of the top level configurations were used for files within directories with separate package.json files. Once I removed these local package.json files from the components sub-directory, all the prior issues were resolved. One hallmark of this problem is that compilation errors were not showing up for JavaScript files that weren't nested under an alternate package.json file.
Hopefully this is useful for anyone that encounters similar errors as I don't think the cause can be directly determined from the compiler messages alone.
I am converting code from javascript to typescript as a part of a migration process.
I need to import 'xyz.css' file in my another file like 'abc.ts'. both the files are in the same directory. I am importing the file as follows :
import '../../xyz.css';
and it gives me an error :
relative modules were not found:
'../../../xyz.css' in '../../dist/abc.js'
This error occurs while webpack compilation process.
Please give a suggestion to resolve same.
Thanks!
For non-node_modules based modules, you should use a path, usually a relative path. So if you're trying to reference xyz.css from the same directory as your typescript file, you would use
import './xyz.css';
Our project is using the webpack resolve.root option to import modules with absolute paths. (avoiding something like ../../../module)
In its current state the project is using babel-loader which works perfectly fine.
My task is to migrate the app to Angular 2.
Therefor I am currently in the process of transitioning to TypeScript.
Somehow it seems like the ts-loader does not work in combination with the resolve.root option of the webpack config.
Example of the webpack.config.js
resolve: {
root: [
path.resolve('./node_modules'),
path.resolve('./app'),
path.resolve('./app/lib'),
]
},
Example of a module import
import AbstractListState from 'states/abstract_list_state';
The states directory is inside the app/lib directory.
Error when executing webpack
ERROR in ./app/mainViews/panel/panel.controller.ts
Module not found: Error: Cannot resolve module 'states/abstract_list_state' in C:\Users\...\Project\app\mainViews\panel
# ./app/mainViews/panel/panel.controller.ts 4:28-65
Pre version 2.0 TypeScript will try to load modules with an absolute path from the node_modules directory. This is because TypeScript's module resultion is per default set to "node". Which means it works like node's require method. So, even if you're using webpack to build your app, TypeScript (and its compiler) will still want to load the files.
In order to let webpack import your modules with absolute path you have to go back and use the require method. This way TypeScript will let webpack import stuff. But of course you will not get any type-inference, autocomplete, ...
Or, you update to the TypeScript 2.0 beta and give this a try: https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#module-resolution-enhancements-baseurl-path-mapping-rootdirs-and-tracing