When using a custom server, trying to import a .ts
file from outside of the dir
directory results in the following error:
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file.
// server.ts
const app = next({
dev: true,
dir: path.resolve(__dirname, './src')
});
Create a different .ts
file outside of ./src
Create a page and try to import the .ts file outside of ./src
// src/pages/index.tsx
import config from '../../config'
The file is imported correctly with no errors
I am using ts-node
to execute the server file.
Hello! Next.js does not support importing assets from outside of your base directory.
This includes JavaScript files, which won't be transformed by Babel.
Maybe we can add a slightly friendlier error message here.
Ok, I didn't realize this.
I think it would be nice to be able to have more flexibility in my project structure. One change that would be nice would to be able to specify where the 'pages' directory is, rather than just the whole base directory (I'm sure theres a reason this isn't currently possible - but it would be nice!).
Maybe something like:
const app = next({
dev: true,
dir: path.resolve(__dirname, './src'),
pages: path.resolve(__dirname, './src/client/pages')
});
Thanks anyways!
@lbittner-pdftron we're not going to allow that, this has been discussed many times before: https://github.com/zeit/next.js/issues/4315
You can solve this by organising your code with Yarn workspaces.
Config could be a separate @app/config
npm package that you import in your application. You can then use next-transpile-modules: withTranspileModules({ transpileModules: ['@app/config'] })
if you want to use the same transpilation settings as your Next.js application.
I am getting this same error when using an npm package that is not compiled to js. Any help with this would be great
System information
OS: macOS
Next.js 9.1.5
I agree with @Timer鈥攖here should be a much friendlier error message here. Just spent a few hours debugging this... my first instinct was to dig into the TS-related webpack/babel config, which leads on a series of rabbit trails orthogonal to the simple problem of file location
Another use case of this would be to have a monorepo where mobile and web project sharing the same logic, but without making that sharable code a "repo" itself. Reason for doing that is some tools (react native) don't like symlinks created by yarn workspaces, or multiple instances of the same dependency (e.g. react, react-native) without symlinks. So it could make things a lot easier to just have a folder of files sitting outside of any repo, and just grab them if you need them by import { Auth } from '../shared/components'
.
next-transpile-modules should do the trick.
If anyone wants to try to tackle this you can look at how we do CSS here:
https://github.com/vercel/next.js/blob/792a113d482b770f412403b4a0d33b3451bac23d/packages/next/build/webpack/config/blocks/css/index.ts#L152-L167
https://github.com/vercel/next.js/pull/13542 solves this issue I think
13542 solves this issue I think
It does partially : if tsconfig declares a baseUrl
that's a parent of the file being imported.
@timneutkens congrats! This long awaited feature finally works BUT it does not recompile on change of above-cwd files.
Is it important? IDK man. I'd say yes and you should make it a top prio on your roadmap. fwiw, we just trashed Next for all of our packages except some dumb seo/leadgen sites because of the subpar interoperability with other systems.
With proper code sharing, being DRY and multiple front end entities you just cant put everything into a Next folder (maybe for some hobby sites). Monorepos and project references are the new normal and Next should obey and recompile on change of any imported file within baseUrl
.
Most helpful comment
Another use case of this would be to have a monorepo where mobile and web project sharing the same logic, but without making that sharable code a "repo" itself. Reason for doing that is some tools (react native) don't like symlinks created by yarn workspaces, or multiple instances of the same dependency (e.g. react, react-native) without symlinks. So it could make things a lot easier to just have a folder of files sitting outside of any repo, and just grab them if you need them by
import { Auth } from '../shared/components'
.