So I've got a monorepo I am trying to use based on this one:
https://github.com/GeekyAnts/nativebase-templates/tree/master/solito-universal-app-template-nativebase-typescript
This repo has 4 separate places where there is a package.json (and theoretically a tsconfig.json) - the app is partially TypeScript and partially Javascript (re-writing it gradually in TypeScript as time goes along)
Basically the directory structure looks like this:
/ - root directory
/apps/expo - expo-related packages, configurations, functions, etc
/apps/next - next-related packages, configuration, functions, etc
/packages/app/ - general business logic, code, pages, etc
No matter what I am trying to do or where I am trying to setup the routing, it isn't working.
Inside my tsconfig.json in my root folder, I have this (I have also tried putting it in the individual tsconfig.json files of the individual folders):
"paths": {
"app/*": ["./packages/app/*"],
"components/*": ["./packages/app/components"],
"config/*": ["./packages/app/config"],
"controllers/*": ["./packages/app/controllers"],
"pages/*": ["./packages/app/pages"],
"reducers/*": ["./packages/app/redux"],
"resources/*": ["./packages/app/resources"],
"revenuecat/*": ["./packages/app/revenuecat"],
"routing/*": ["./packages/app/routing"],
"utils/*": ["./packages/app/utils"],
"interfaces/*": ["./packages/app/interfaces"],
"root/*": ["./*"]
}
But none of these paths are recognized in my Next app.
I've tried putting in the babel.config.js of the Expo folder inside my plugins:
[
'module-resolver',
{
root: '../../packages',
alias: {
app: '../../packages/app',
components: '../../packages/app/components',
config: '../../packages/app/config',
controllers: '../../packages/app/controllers',
pages: '../../packages/app/pages',
reducers: '../../packages/app/redux',
resources: '../../packages/app/resources',
revenuecat: '../../packages/app/revenuecat',
routing: '../../packages/app/routing',
utils: '../../packages/app/utils',
interfaces: '../../packages/app/interfaces',
},
},
]
I've tried putting them in the .babelrc of the Next folder, also in my plugins:
[
"module-resolver",
{
"root": "../../packages",
"alias": {
"app/*": "../../packages/app",
"components": "../../packages/app/components",
"config": "../../packages/app/config",
"controllers": "../../packages/app/controllers",
"pages": "../../packages/app/pages",
"reducers": "../../packages/app/redux",
"resources": "../../packages/app/resources",
"revenuecat": "../../packages/app/revenuecat",
"routing": "../../packages/app/routing",
"utils": "../../packages/app/utils",
"interfaces": "../../packages/app/interfaces"
}
}
]
The code I am trying to run is my _app.js which calls my Footer file in my /packages/app/components/main folder. The _app.js works fine and it gets to my Footer.web.js file, but then I get:
error - ../../packages/app/components/main/Footer.web.js:4:0
Module not found: Can't resolve 'components/main/AppButtons'
2 | import { FontAwesome } from '#expo/vector-icons';
3 | import moment from 'moment';
> 4 | import AppButtonGroup from 'components/main/AppButtons';
5 | import {
6 | Row,
7 | Column,
Now Appbuttons.tsx is in the same folder as Footer.web.js
My guess is that I need another .babelrc file for my /packages/app folder? Or is it another error?
My workspaces are set like this in my root package.json:
"workspaces": [
"apps/*",
"packages/*"
],
What is causing this to not work? Why is my pathing not working in my /packages/app folder?
Solution
Add your path alias into the workspace root tsconfig.json, also add "baseURL": "./".
{
"compilerOptions": {
+ "baseUrl": "./",
"strictNullChecks": true,
"noUncheckedIndexedAccess": true,
"paths": {
"app/*": ["./packages/app/*"],
+ "components/*": ["./packages/app/components/*"],
+ "config/*": ["./packages/app/config"],
// ...
Config for next, install tsconfig-paths-webpack-plugin, go to apps/next/next.config.js and apply this plugin:
const path = require('node:path');
const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');
// ...
module.exports = withNativebase({
// ...
nextConfig: {
webpack: (config, options) => {
// ...
config.resolve.plugins = [
...config.resolve.plugins,
new TsconfigPathsPlugin({
// Use the root `tsconfig.json`!
configFile: path.resolve(__dirname, '../../tsconfig.json'),
}),
]
return config
},
Config for expo, go to apps/expo/babel.config.js:
const path = require('node:path');
// ...
plugins: [
'react-native-reanimated/plugin',
[
'module-resolver',
{
root: path.resolve(__dirname, '../../'),
alias: {
app: './packages/app',
components: './packages/app/components',
// ...
},
},
]
]
Explanation
First of all, let's me spit it out, I personally would've just use "app/components/*" as alias, so to avoid this config madness. But since you asked, here's the answer. See above for the solution, and below is some nerdy explanation on technical details. Skip if you don't care.
Truth of the app/* pseudo-alias
Without above config, only app/* alias works. But the reason's kinda special: this is NOT a real (in bundle tool's term) alias. It's in fact a real filesystem symlink <root>/node_modules/app -> <root>/packages/app.
This symlink is created by yarn/npm's workspace mechanism. Because it lives in <root>/node_modules, the alias-ish app/* path is actually resolved as if it's a real npm package.
One does not simply use alias
Now if you want to add your own real alias, you'll have to wrestle with build tools.
The template you use has two tooling setup: next for web, expo for native. You need to address them separately.
In this case, tsconfig.json -> compilerOptions.paths is mainly for IDE hint (e.g. vscode jump to definition). By default it's not used by either tools. So you still need to manually config alias via plugins like I've shown in solution section.
So yeah, 3 configs for 3 tools, madness.
Revisit pseudo-alias
Another solution is to leverage the workspace mechanism to create pseudo-alias, like in the case of app/*. For example, if you want components/* as "alias". You need to:
create <root>/packages/components/package.json and give it a "name": "components".
A lil twist: if you use "name": "duck" for whatever reason, your pseudo-alias will become duck/*, i.e., folder name does NOT matter. Only package name matters.
cd back to project root dir, and simply run yarn, you should now see a symlink at <root>/node_modules/components.
(optional step) You are supposed to add into "dependencies": { "components": "*" } in other workspace package's package.json (e.g., apps/next/package.json) if you want to use this components/* "alias", because it's in fact is another package named "components" that you depend on. It's a good practice to add dep package into "dependencies" field.
Quite laborious too, I know. But still an option.
This does not answer your question, because you do not use webpack, but you can try this tool. The code will look like below.
Try to start your paths from "#".
Try to move your config into the root folder.
const {resolve} = require("path");
const TsConfigPathsPlugin = require("tsconfig-paths-webpack-plugin");
// ...
module.exports = {
entry: "./packages/app/index.tsx",
target: "web",
output: {
path: resolve(__dirname, "build"),
filename: "[name].js",
publicPath: "/",
chunkFilename: "[name].chunk.js"
},
// ...
resolve: {
extensions: [".js", ".jsx", ".json", ".ts", ".tsx"],
plugins: [new TsConfigPathsPlugin()],
alias: {
"#": resolve(__dirname, "packages/app"),
"#components": resolve(__dirname, "packages/app/components"),
"#config": resolve(__dirname, "packages/app/config"),
"#pages": resolve(__dirname, "packages/app/pages"),
// ...
}
},
// ...
};
tsconfig will look like this:
{
"compilerOptions": {
"jsx": "react",
"module": "commonjs",
"noImplicitAny": true,
"outDir": "./build/",
"preserveConstEnums": true,
"removeComments": true,
"sourceMap": true,
"target": "es2015",
"esModuleInterop": true,
"baseUrl": "./packages/app",
"strict": true,
"moduleResolution": "node",
"resolveJsonModule": true,
"paths": {
"#components/*": ["./components/*"],
"#components": ["./components"],
"#config/*": ["./config/*"],
"#config": ["./config"],
"#pages/*": ["./pages/*"],
"#pages": ["./pages"],
// ...
"#/*": ["./*"]
}
},
"include": [
"packages/app"
]
}
I would do something basic which might not work for your use case,
I'd use npm install <folder>
Since these dirs are npm packages,
/ - root directory
/apps/expo - expo-related packages, configurations, functions, etc
/apps/next - next-related packages, configuration, functions, etc
/packages/app/ - general business logic, code, pages, etc
If I wanted to access /packages/app/ in apps/next dir, I'd do,
cd apps/next
npm install ../../packages/app --install-links
Assuming the name of package packages/app (in package.json) is my-app-packages I'd just use those like so,
import Routing from "my-app-packages/routing";
I believe you accidentally added /* to the end of all path like app/*. Try changing your paths in tsconfig.json like below
"paths": {
"app/*": ["./packages/app/*"],
"components": ["./packages/app/components"],
"config": ["./packages/app/config"],
"controllers": ["./packages/app/controllers"],
"pages": ["./packages/app/pages"],
"reducers": ["./packages/app/redux"],
"resources": ["./packages/app/resources"],
"revenuecat": ["./packages/app/revenuecat"],
"routing": ["./packages/app/routing"],
"utils": ["./packages/app/utils"],
"interfaces": ["./packages/app/interfaces"],
"root": ["./*"]
}
I have a directory structure like
- project
|- build
|- src
|- index.ts
|- file.txt
The typescript is compiled to the build directory and executed from there. I'm looking for a reliable way to access file.txt from the compiled module without having to account for the location of the build output.
For example, I could just assume that the file is at ../src/file.txt relative to the index.js in build but if the build output changes, that needs to be changed as well.
Is there possibly a way to pass root directory into an environment variable before the typescript is compiled?
If you using webpack, you can insert a resolve, see documentation: https://webpack.js.org/configuration/resolve/
and a example:
const path = require('path');
module.exports = {
//...
resolve: {
alias: {
Utilities: path.resolve(__dirname, 'src/utilities/'),
Templates: path.resolve(__dirname, 'src/templates/'),
},
},
};
You can too use vscode jsconfig.json you can use compilerOptions, see documentation: https://code.visualstudio.com/docs/languages/jsconfig
example:
{
...
"compilerOptions": {
"target": "es2015",
"module": "esnext",
"baseUrl": ".",
"paths": {
"#assets/*": ["src/assets/*"],
"#background/*": ["src/background/*"],
"#frontend/*": ["src/frontend/*"],
"#mixins/*": ["src/frontend/mixins/*"]
}
}
}
I have a lerna monorepo containing lots of packages.
I'm trying to achieve the following:
Ensure that VSCode provides the correct import suggestions (based on package names, not on relative paths) from one package to another.
Ensure that I can 'Open Definition' of one of these imports and be taken to the src of that file.
For 1. I mean that if I am navigating code within package-a and I start to type a function exported by package-b, I get a suggestion that will trigger the adding of an import: `import { example } from 'package-b'.
For 2. I mean that if I alt/click on the name of a function exported by 'package-b' while navigating the file from a different package that has imported it, I am taken to '/packages/namespace/package/b/src/file-that-contains-function.js',
My (lerna) monorepo is structured as standard, for example here is a 'components' package that is published as #namespace/components.
- packages
- components
- package.json
- node_modules
- src
- index.js
- components
- Button
- index.js
- Button.js
- es
- index.js
- components
- Button
- index.js
- Button.js
Note that each component is represented by a directory so that it can contain other components if necessary. In this example, packages/components/index exports Button as a named export. Files are transpiled to the package's /es/ directory.
By default, VSCode provides autosuggestions for imports, but it is confused by this structure and, for if a different package in the monorepo needs to use Button for example, will autosuggest all of the following import paths:
packages/components/src/index.js
packages/components/src/Button/index.js
packages/components/src/Button/Button.js
packages/components/es/index.js
packages/components/es/Button/index.js
packages/components/es/Button/Button.js
However none of these are the appropriate, because they will be rendered as relative paths from the importing file to the imported file. In this case, the following import is the correct import:
import { Button } from '#namespace/components'
Adding excludes to the project's jsconfig.json has no effect on the suggested paths, and doesn't even remove the suggestions at /es/*:
{
"compilerOptions": {
"target": "es6",
},
"exclude": [
"**/dist/*",
"**/coverage/*",
"**/lib/*",
"**/public/*",
"**/es/*"
]
}
Explicitly adding paths using the "compilerOptions" also fails to set up the correct relationship between the files:
{
"compilerOptions": {
"target": "es6",
"baseUrl": ".",
"paths": {
"#namespace/components/*": [
"./packages/namespace-components/src/*.js"
]
}
},
}
At present Cmd/Clicking on an import from a different package fails to open anything (no definition is found).
How should I configure VSCode so that:
VSCode autosuggests imports from other packages in the monorepo using the namespaced package as the import value.
Using 'Open Definition' takes me to the src of that file.
As requested, I have a single babel config in the root:
const { extendBabelConfig } = require(`./packages/example/src`)
const config = extendBabelConfig({
// Allow local .babelrc.js files to be loaded first as overrides
babelrcRoots: [`packages/*`],
})
module.exports = config
Which extends:
const presets = [
[
`#babel/preset-env`,
{
loose: true,
modules: false,
useBuiltIns: `entry`,
shippedProposals: true,
targets: {
browsers: [`>0.25%`, `not dead`],
},
},
],
[
`#babel/preset-react`,
{
useBuiltIns: true,
modules: false,
pragma: `React.createElement`,
},
],
]
const plugins = [
`#babel/plugin-transform-object-assign`,
[
`babel-plugin-styled-components`,
{
displayName: true,
},
],
[
`#babel/plugin-proposal-class-properties`,
{
loose: true,
},
],
`#babel/plugin-syntax-dynamic-import`,
[
`#babel/plugin-transform-runtime`,
{
helpers: true,
regenerator: true,
},
],
]
// By default we build without transpiling modules so that Webpack can perform
// tree shaking. However Jest cannot handle ES6 imports becuase it runs on
// babel, so we need to transpile imports when running with jest.
if (process.env.UNDER_TEST === `1`) {
// eslint-disable-next-line no-console
console.log(`Running under test, so transpiling imports`)
plugins.push(`#babel/plugin-transform-modules-commonjs`)
}
const config = {
presets,
plugins,
}
module.exports = config
In your case, I would make use of lerna in combination with yarn workspaces.
When running yarn install, all your packages are linked under your #namespace in a global node_modules folder. With that, you get IntelliSense.
I've set up an example repository here: https://github.com/flolude/stackoverflow-lerna-monorepo-vscode-intellisense
You just need to add "useWorkspaces": "true" to your lerna.json
lerna.json
{
"packages": ["packages/*"],
"version": "0.0.0",
"useWorkspaces": "true"
}
And the rest is just propper naming:
global package.json
{
"name": "namespace",
// ...
}
package.json of your component package
{
"name": "#namespace/components",
"main": "src/index.js",
// ...
}
package.json of the package that imports the components
{
"name": "#namespace/components",
"main": "src/index.js",
"dependencies": {
"#namespace/components":"0.0.0"
}
// ...
}
Then you can do the following:
import { Component1 } from '#namespace/components';
// your logic
Automatically Importing from #namespace
Unfortunately, I couldn't find a way to make this work in VSCode with a Javascript Monorepo. But there are some things you can do:
Use Typescript (tutorial, other tutorial)
Use module-alias
Add import {} from '#namespace/components' to the top of your file
Use Auto Import Extension
Edit: This is broken with the latest version of VSCode.
I finally managed to get this working reliably. You need to create a separate jsconfig.js for every package in your monorepo, for example:
{monorepo root}/packages/some-package/jsconfig.json:
{
"compilerOptions": {
"target": "es6",
"jsx": "preserve",
"module": "commonjs"
},
"include": ["src/**/*.js"],
"exclude": ["src/index.js"]
}
Note that I've excluded the src/index.js file so it doesn't get offered as an import suggestion from within that package.
This setup appears to achieve:
Intellisense import suggestions from packages instead of using relative paths.
Go to definition to source of other packages in the monorepo.
VSCode has been pretty flaky of late, but it seems to be working.
Note this is working for a JavaScript-only monorepo (not Typescript).
How can I compile my Typescript project into a TS compilation so I can then import it into other TS projects and use the type definitions? For backward compatibility, I also want to export them as pure JS too so others who don't use TS, can still use the project.
You need to publish your project as an npm package. You can create a private package on npm if you want (but you need a paid account for that), or you can publish it publicly, or you can use sinopia, which is basically a local instance of npm.
Any one of these options requires you to have an up to date package.json file that specifies your project's dependencies.
You will be publishing your package in compiled form. So, if you specify your tsconfig and package.json properly, you will be exporting js files along with d.ts. files and the package will be usable either by typescript or vanilla javascript.
This is how I've done it:
// package.json
// The property name: #my-org/... means that the package is scoped -
// you can point a #scope at a specific NPM registry.
// See https://docs.npmjs.com/misc/scope
// We use myget.org to host our private packages.
{
"name": "#my-org/ng-lib",
"version": "1.0.8",
"main": "dist/index.js",
"scripts": {
"transpile": "tsc --outDir ./",
"clean": "rimraf ./services && rimraf ./*.js && rimraf ./*.d.ts"
},
"author": "*** <me#my-org.com>",
"license": "ISC",
"files": [
"**/*.js",
"**/*.d.ts"
],
"typings": "index.d.ts",
"dependencies": {
"#types/angular": "^1.5.20",
"angular": "^1.5.9"
},
"devDependencies": {
"rimraf": "^2.5.4"
}
}
EDIT:
Notice the "typings": "index.d.ts" line? That describes the main "types" file for the package. So when you do an import * as ngLib from '#my-org/ng-lib' it will use the typings from node_modules/#my-org/ng-lib/index.d.ts for intellisense, and upon transpile webpack will find the main js file at node_modules/#my-org/ng-lib/dist/index.js
So if you've created an index.d.ts by hand and all you've got to export are interfaces you can point the typings field at that index.d.ts as interfaces have no implementation, and just describe the shape of an object.
However, if you've got objects with logic (methods, getters/setters, etc) they will more than likely be classes, which you'll need to transpile down to .js AND .d.ts files.
EXAMPLE:
./index.ts # Re-exports both my-class and my-interface
./my-class.ts # Implements my-interface.d.ts
./my-interface.d.ts
This output of this after transpile should be as follows in a "typed" NPM package:
./index.d.ts
./index.js
./my-class.js
./my-class.d.ts
./my-interface.d.ts
And package.json will include the following lines:
"main": "./index.js",
"typings": "./index.d.ts",
"files": [
"./index.d.ts",
"./index.js",
"./my-class.js",
"./my-class.d.ts",
"./my-interface.d.ts"
]
... and when consuming the package (once it's published and installed in another project) can be done in the following ways:
import * as ngLib from '#my-org/ng-lib'
import { MyClass } from '#my-org/ng-lib'
import { MyInterface } from '#my-org/ng-lib'
import { MyClass } from '#my-org/ng-lib/my-class'
import { MyInterface } from '#my-org/ng-lib/my-interface'
END EDIT
The declaration property in tsconfig.json will emit .d.ts files describing the 'shape' of your exported objects.
// tsconfig.json
{
"compilerOptions": {
"target": "es5",
"module": "commonjs",
"sourceMap": false,
"emitDecoratorMetadata": true,
"declaration": true,
"experimentalDecorators": true,
"removeComments": true,
"noImplicitAny": false,
"suppressImplicitAnyIndexErrors": false,
"baseUrl": "./src",
"listFiles": true,
"noImplicitUseStrict": false
},
"exclude": [
"node_modules"
]
}
And if it's a complicated package, I'll have separate modules and aggregate them in the index.ts like so:
// index.ts
export * from './module-one'
export * from './module-two'
export * from './module-three'
You can also have sub-directories, each with their own indexes.
This will create both the index.js and index.d.ts files, which allows the following:
import * as ngLib from '#my-org/ng-lib'
import { ModuleOne } from '#my-org/ng-lib/module-one'
import { SubModuleOne } from '#my-org/ng-lib/submodules/submodule-one'