Open SimeonC opened 4 years ago
On a related note I am interested in trying this out on my project but alongside this particular problem (we use src/
as an alias for source code and keep every import absolute), in addition our structure is a monorepo via yarn workspaces
- as such if I update file locations in one of the subpackages the other subpackages need to change their references to the shared repo as well. Probably a sufficiently separate issue to be its own ticket, but maybe if we could lock down some files/imports as the "public surface" of a package that might be useful too.
@osdiab Hi, what are you using to alias src/
? Typescript's aliases? We're trying to find every possible ways to tweak the js imports so Destiny would be able to resolve non-vanilla js imports (see #123) out of the box.
in addition our structure is a monorepo via yarn workspaces
This is already tracked in #70.
My company basically relies on baseUrl
to do it:
packages/api/
), we just set the baseUrl
to .
at the project root, and restrict the include
field to ["src"]
{
"extends": "./tsconfig.api.base.json",
"compilerOptions": {
// ...
"baseUrl": "."
},
"references": [{ "path": "../common/" }],
"include": ["src", "types"]
}
packages/api/__tests__/
), it has its own tsconfig
that extends the API's tsconfig
, but includes the API itself as a project reference.{
"extends": "../tsconfig.json",
"compilerOptions": {
"noEmit": true,
"types": ["jest", "node"]
},
"references": [{ "path": "../" }, { "path": "../../common" }],
"include": ["./", "../types"]
}
packages/website/
), which uses create-react-app
, we can only set baseUrl
to src/
(thats a CRA limitation). So, we placed our code all in packages/website/src/@app
and refer to web app code as @app/path/to/ReactComponent
.{
"extends": "../tsconfig.base.json",
"compilerOptions": {
// ...
"baseUrl": "./src",
},
"references": [{ "path": "../common" }],
"include": ["src"]
}
For imports internal to these packages, that covers our use case! EDIT: for imports across subpackages, ie from API to common package, we rely on yarn
workspaces, which routes imports to files via each subpackage's package.json
name
property - but I assume that might be harder to account for.
Thank you! I've added Yarn workspaces and TSC's baseUrl
to the list in #123.
In our projects we make heavy use of flow's module.name_mapper and also babel's module alias configuration. This lets us make imports like this
import SideNav from 'modules/SideNav';
.Then in .flowconfig we have
module.name_mapper='^modules/\(.*\)$' -> '<PROJECT_ROOT>/src/modules/\1'
But this doesn't work in destiny as they aren't relative paths and the graph can't be built. I don't know if this issue becomes irrelevant when using destiny or not, but it does make it harder to start using it.