Comments (10)
Yes but none of my packages have paths, and it still doesn't work. So having path aliases set in the package was not the problem as you suggested.
@BenJackGill Ah that's a bit of a misunderstanding I think. I never wanted to suggest that path aliases are the cause of your problem. I wanted to point out that the no-build approach might not be viable if you are not willing to give up on using path aliases, and that's why I never tried to make it work.
To get back to your question about isolate. I think you need to make sure "files" are pointing to your src directory. Then you should see the source files being packaged and copied into the isolate directory. Then if your types and main entries point to the source directory as well, I think it could work maybe...
But what @piedrahitapablo explained about setting specific aliases in each package, I suspect that will still break things, because the isolated packages will not have a tsconfig file and even if we make it so that the tsconfig files are included in the isolated output, the alias paths configurations for each would need to be altered I think.
--- edit ---
Actually, you have full control over which files are included in the isolated output. Because you can specify a list of files and globs in the "files" field of the manifest. So you could just that to include the tsconfig file probably. But I don't expect it to work without altering the paths in the configs.
from isolate-package.
@BenJackGill Happy to report that I have it working without issues! My monorepo example uses both the traditional and internal packages approach. Check it out https://github.com/0x80/mono-ts
It also demonstrates the firebase-tools fork I've made to preserve live code updates when running the emulators
from isolate-package.
I tried that, and it sounds nice, but I think it falls apart once you start using path aliases.
I love my aliases too much to give them up. I expect one day the tooling will allow us to write TS without having to jump through hoops building every package, but I don't think we're there yet. I would expect more sources advocating it, if it was a viable solution.
So personally, I'm not interested in going down what path if I can't use path aliases, and I'm not sure if isolate-package would need to change to accommodate it. I suspect the solution lies outside of its context.
I think it will still gather the shared packages code and point dependencies to each other if you set the "files" field in each manifest to be the src folder instead of the build output. Because the "files" is what's being picked up by the pack
executable.
So you could give it a try...
from isolate-package.
Do you mean paths in the packages or paths in the app?
Because my packages do not have any paths. They don't even have a tsconfig.json
file. I am relying on the consuming app to process the TypeScript as per it's own tsconfig.json
file. But unfortunately isolate-package
doesn't seem to work with that setup. Maybe there is something else going on though. I'll try debug it later :)
from isolate-package.
I'm talking about path aliases like I have ~
pointing go src
for each package. If your app imports code from packages that have ~/ in the imports path, and the app itself is also using ~/ to map to its own src folder, than it won't find things.
from isolate-package.
Yes but none of my packages have paths, and it still doesn't work. So having path aliases set in the package was not the problem as you suggested. Those paths are set in the tsconfig.json
file and my packages don't even have a tsconfig.json
file because I am importing it directly into the app without any transpiling.
from isolate-package.
The way to do it is building using the tsup-node
command from tsup and the noExternal
config. Here's the config I used:
// tsup.config.ts
import { defineConfig } from 'tsup';
export default defineConfig({
entry: ['src/index.ts'],
sourcemap: true,
clean: true,
target: 'node18',
noExternal: [
'@my-org/pkg1',
'@my-org/pkg2',
],
});
Regarding the aliases inside packages, unfortunately you will need to define an unique alias for each package, so for example in the tsconfig.json
of the internal package:
{
"compilerOptions": {
...
"paths": {
"@/pkg1/*": "./src/*"
}
}
}
and in the tsconfig.json
of the app:
{
"compilerOptions": {
...
"paths": {
"@/pkg1/*": "../../packages/pkg1/src/*"
}
}
}
I think it's a small price to pay to remove the need for local builds in development.
from isolate-package.
@piedrahitapablo Interesting. Good to hear that it can work! Having unique path aliases for each package is indeed a small price to pay.
I do think it can lead to code duplication because if I understand it correctly it is inlining the code from shared dependencies inside each package. So if you have package A depending on B and C, And you also have package B depending on C, then code for A will be the result of A+BC*+C
But this might still be very acceptable.
from isolate-package.
@BenJackGill Did you manage to make it work?
I will now explore the no-build approach myself, as I realized that I don't need path aliases for my shared packages. Only for the apps and services that get deployed, because shared packages typically do not have deeply nested file structures anyway.
from isolate-package.
Sorry I did not get it working. So I switched over to a Vite bundling solution as described here.
It's fast, works without the need for building internal packages, and can use with the emulator.
I'm not exactly sure how it handles lock files though, that's my next thing to investigate.
from isolate-package.
Related Issues (20)
- Add support for Rush monorepos HOT 17
- Add support for passing CLI arguments HOT 6
- pnpm overrides are breaking gcp deployments HOT 7
- Failing to pack with PNPM HOT 4
- There are types at 'isolate-package/dist/index.d.ts', but this result could not be resolved when respecting package.json "exports". HOT 7
- Isolate seem to be not copying the `.env` file HOT 2
- Remove excess packages from the list in pnpm lockfile
- Fix package registry logic for non-rush repositories
- Strip forceNpm option for sake of simplicity
- Reintroduce excludeLockfile
- Add support for pnpm v9 HOT 4
- trouble shooting some problems HOT 3
- Consistently use pnpm pack if suitable
- Adopt packageManager field from root manifest
- Add flag to omit packageManager field
- Define config using a typed function
- Option to prevent move of node_modules for NPM HOT 3
- Will fail if pnpm-workspace.yaml is empty HOT 2
- Handle non-monorepo setups
- Isolated pnpm lockfile is missing overrides HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from isolate-package.