You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A common pattern for managing large TypeScript projects is to leverage tsconfig.json with extends, baseUrl and paths. This is especially true for mono repo projects where it's common to move publishable packages outside of the main application tree into a libs directory.
In these scenarios, TypeScript users are usually able to configure aliases for the intended remote package paths (for libraries that are to be published). This is usually achieved using baseUrl and paths. However, according to the Parcel documentation found here, Parcel currently does not leverage baseUrl and paths and instead makes use of the ~ notation.
Part of the problem with this approach is it adds a lot of import path friction for packages intended to be published to remote repositories (such as NPM). As Parcel doesn't leverage baseUrl and path it means the import paths for a Parcel based application needs to be different than the aliased TS paths used elsewhere within a project. This has a nasty flow on effect where common project tasks (such as renaming and moving library packages) becomes overly difficult, as one needs to maintain two separate import path schemes when this could just be handled by updating a single tsconfig.json alias paths setting.
To illustrate a minimum ideal setup to handle this kind of use case, see the below directory structure with minimum tsconfig.json configurations below.
Directory Structure
apps/
parcel-app/
index.html
index.css
index.ts # import { Foo } from '@org/foo'
tsconfig.json
libs/
foo/ # to be published to @org/foo
index.ts
tsconfig.json
bar/ # to be published to @org/bar
index.ts
tsconfig.json
tsconfig.json
Configurations
To achieve local aliasing for potential remote packages, one could configure the following tsconfig.json in the project root.
// apps/parcel-app/tsconfig.json{"extends" : "../../tsconfig.json",// baseUrl and paths are not supported in Parcel :("files": ["index.ts"]}
TypeScript Path Aliasing is a Relative Path Rewrite
Using the tsc compiler on its own, the aliased import paths are simply rewritten to be relative paths as follows.
import{Foo}from'@org/foo'// compiles as '../../libs/foo/index'
I'm not sure of the current Parcel compilation pipeline for TypeScript, or if there are technicalities working though an intermediate Babel pipeline that would make utilizing this functionality difficult. But thought I'd mention this in case it lends insight into how this feature could be handled with the existing Parcel build pipeline.
The text was updated successfully, but these errors were encountered:
@mischnic Yes :) that issue does indeed seem to be related. I wonder if keeping this issue open may serve to provide an downstream use case for the feature. With the example Directory Structure and TSConfigs used to validate the expected behavior of the feature.
sinclairzx81
changed the title
Feature Request: Support TypeScript TSConfig 'extends', 'baseUrl' and 'paths'
Usecase: Support for TypeScript TSConfig 'extends', 'baseUrl' and 'paths'
Apr 2, 2021
@mischnic Have updated the Issue title. Maybe it its helpful to have a reference project layout to validate the feature. Will leave here for the maintainers to close if necessary. Thanks for the reference to #4936. Will track things there :)
Update: In reference to #4936
A common pattern for managing large TypeScript projects is to leverage
tsconfig.json
withextends
,baseUrl
andpaths
. This is especially true for mono repo projects where it's common to move publishable packages outside of the main application tree into alibs
directory.In these scenarios, TypeScript users are usually able to configure aliases for the intended remote package paths (for libraries that are to be published). This is usually achieved using
baseUrl
andpaths
. However, according to the Parcel documentation found here, Parcel currently does not leveragebaseUrl
andpaths
and instead makes use of the~
notation.Part of the problem with this approach is it adds a lot of
import
path friction for packages intended to be published to remote repositories (such as NPM). As Parcel doesn't leveragebaseUrl
andpath
it means theimport
paths for a Parcel based application needs to be different than the aliased TS paths used elsewhere within a project. This has a nasty flow on effect where common project tasks (such as renaming and moving library packages) becomes overly difficult, as one needs to maintain two separateimport
path schemes when this could just be handled by updating a singletsconfig.json
aliaspaths
setting.To illustrate a minimum ideal setup to handle this kind of use case, see the below directory structure with minimum
tsconfig.json
configurations below.Directory Structure
Configurations
To achieve local aliasing for potential remote packages, one could configure the following
tsconfig.json
in the project root.Then extend the root config for each
lib
andapp
as follows (all are identical)TypeScript Path Aliasing is a Relative Path Rewrite
Using the
tsc
compiler on its own, the aliasedimport
paths are simply rewritten to be relative paths as follows.I'm not sure of the current Parcel compilation pipeline for TypeScript, or if there are technicalities working though an intermediate Babel pipeline that would make utilizing this functionality difficult. But thought I'd mention this in case it lends insight into how this feature could be handled with the existing Parcel build pipeline.
The text was updated successfully, but these errors were encountered: