Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to translate the entire project directory? #263

Closed
ghost opened this issue Jul 16, 2020 · 7 comments
Closed

How to translate the entire project directory? #263

ghost opened this issue Jul 16, 2020 · 7 comments

Comments

@ghost
Copy link

ghost commented Jul 16, 2020

Sorry for the stupid question. Is it possible to use your utility to translate ALL project files from one format (ts/tsx), recursively, to a directory of js files with a similar structure, as does the typescript or babel?

@evanw
Copy link
Owner

evanw commented Jul 18, 2020

This is a bundler, and it's intended use case is for bundling. So what you're asking for is not the intended use case. But I believe it should basically be possible. If you need to do that you could either:

  • Pass all of the files to esbuild explicitly. You can either list them out yourself like this:

    esbuild [file1] [file2] ... --outdir=out
    

    or use another command to generate the list:

    esbuild `find . \( -name '*.ts' -o -name '*.tsx' \)` --outdir=out
    
  • Build something yourself that does this using esbuild's JavaScript API or Go API.

  • Use an existing solution that's designed for this such as the TypeScript compiler. I've also heard that swc is designed for this exact use case and is intended to be high performance (e.g. written in Rust) so it could be a good tool to check out.

@ghost
Copy link
Author

ghost commented Jul 18, 2020

@evanw Thank you, I thought so. Just confused by the slogan "Similar tools: Babel or TypeScript for transpiling". This is not entirely true, because "Cannot use" format "without" bundle "". I don't know why someone would need to bundle a single cjs file. Will have to return to sucrase

@evanw
Copy link
Owner

evanw commented Jul 19, 2020

Makes sense. Sorry about the confusion. Looks like this is a request for #109 then, so I'll close this as a duplicate.

@evanw evanw closed this as completed Jul 19, 2020
@Hebilicious
Copy link

@evanw Referencing this community projects here : https://github.com/egoist/tsup as it seems to do what @makoven wanted and is built on top of esbuild and rollup.

@roelandxyz
Copy link

Just for reference. I use this to build my express server typescript files:

  "scripts": {
    "watch": "nodemon --watch server --ext ts --exec 'npm run build && npm run start'",
    "build": "esbuild `find server \\( -name '*.ts' \\)` --platform=node --outdir=build/server",
    "start": "node build/server/index.js",
    "clean": "rimraf build"
  },

(server is an npm workspace/folder for the express server)

@justingolden21
Copy link

Invalid build flag: "-name" when I try roelandmoors's build command

@izakfilmalter
Copy link

izakfilmalter commented Feb 5, 2024

If you are using yarn you will need to change to the following:

    "buld": "esbuild $(find . \\( -name '*.ts' -o -name '*.tsx' \\)) --outdir=out",

Offroaders123 added a commit to Offroaders123/NBTify that referenced this issue Feb 15, 2024
The more I look into this, the more complex it seems, and the less sure I am with both the way I have things now, as well as whether I like the other options instead.

I think I may just stick with TSC for compiling my package code in general, and if anything I can still do/try out the dual-build setup with ESM/CJS, but maybe just use TSC, since I can ensure that things are built consistently.

Should I provide synchronous APIs from NBTify? I think learning about how to work with async has really helped me progress, and I don't want to prevent someone else from learning that if I go with providing a sync option to my API. Or rather, if anything, that would only work in Node, because the Compression Streams API is only an asynchronous implementation. I'd have to use Node Zlib as a fallback to allow for a synchronous implementation, and it would be for Node only. I'm not sure I like the splintering of that either.

I think I have realized afterall, that I don't specifically want to use ESBuild for building my packages, since it's meant to bundle code, and I think I would only want to use that in a situation of building an ESM bundle for the browser. I may look into that as well though. Maybe I can use pkgbuild for that instead though? It kind of works a bit nicer for plain TS type generation support out of the box, as well as the configuation for things just plain working. Maybe I can look into making my own tool kind of like that, since it feels like all of the tools for this that I find, they all don't quite work exactly like how I want them to, unfortunately.

https://www.reddit.com/r/node/comments/14os7zv/the_esmcjs_situation/
https://github.com/wooorm/npm-esm-vs-cjs
https://stackoverflow.com/questions/46515764/how-can-i-use-async-await-at-the-top-level
https://stackoverflow.com/questions/71517624/because-i-cant-run-await-on-the-top-level-i-have-to-put-it-into-an-async-funct
https://commerce.nearform.com/blog/2021/node-esm-and-exports/
https://dev.to/a0viedo/nodejs-typescript-and-esm-it-doesnt-have-to-be-painful-438e
https://www.reddit.com/r/node/comments/14rg9ym/esm_not_gaining_traction_in_backend_node/
nodejs/node#49432
https://github.com/azu/tsconfig-to-dual-package
https://www.breakp.dev/blog/simple-library-package-setup-with-esbuild/
https://esbuild.github.io/api/#build
evanw/esbuild#263
evanw/esbuild#618
microsoft/TypeScript#46005

https://guitar.com/news/music-news/devin-townsend-shredding-dreams-steve-vai/
https://www.reddit.com/r/DevinTownsend/comments/17s332s/devin_and_the_vai_years/
https://www.reddit.com/r/DevinTownsend/comments/k9jot4/devin_townsend_i_was_unable_to_articulate_my/
https://www.kerrang.com/devin-townsend-i-was-unable-to-articulate-my-discontent-so-i-tended-to-act-up-i-even-took-a-sh-t-in-steve-vais-guitar-case
https://www.reddit.com/r/DevinTownsend/comments/6tia0r/is_vai_comparing_devin_to_zappa/
Offroaders123 added a commit to Offroaders123/NBTify that referenced this issue Feb 21, 2024
The more I look into this, the more complex it seems, and the less sure I am with both the way I have things now, as well as whether I like the other options instead.

I think I may just stick with TSC for compiling my package code in general, and if anything I can still do/try out the dual-build setup with ESM/CJS, but maybe just use TSC, since I can ensure that things are built consistently.

Should I provide synchronous APIs from NBTify? I think learning about how to work with async has really helped me progress, and I don't want to prevent someone else from learning that if I go with providing a sync option to my API. Or rather, if anything, that would only work in Node, because the Compression Streams API is only an asynchronous implementation. I'd have to use Node Zlib as a fallback to allow for a synchronous implementation, and it would be for Node only. I'm not sure I like the splintering of that either.

I think I have realized afterall, that I don't specifically want to use ESBuild for building my packages, since it's meant to bundle code, and I think I would only want to use that in a situation of building an ESM bundle for the browser. I may look into that as well though. Maybe I can use pkgbuild for that instead though? It kind of works a bit nicer for plain TS type generation support out of the box, as well as the configuation for things just plain working. Maybe I can look into making my own tool kind of like that, since it feels like all of the tools for this that I find, they all don't quite work exactly like how I want them to, unfortunately.

https://www.reddit.com/r/node/comments/14os7zv/the_esmcjs_situation/
https://github.com/wooorm/npm-esm-vs-cjs
https://stackoverflow.com/questions/46515764/how-can-i-use-async-await-at-the-top-level
https://stackoverflow.com/questions/71517624/because-i-cant-run-await-on-the-top-level-i-have-to-put-it-into-an-async-funct
https://commerce.nearform.com/blog/2021/node-esm-and-exports/
https://dev.to/a0viedo/nodejs-typescript-and-esm-it-doesnt-have-to-be-painful-438e
https://www.reddit.com/r/node/comments/14rg9ym/esm_not_gaining_traction_in_backend_node/
nodejs/node#49432
https://github.com/azu/tsconfig-to-dual-package
https://www.breakp.dev/blog/simple-library-package-setup-with-esbuild/
https://esbuild.github.io/api/#build
evanw/esbuild#263
evanw/esbuild#618
microsoft/TypeScript#46005

https://guitar.com/news/music-news/devin-townsend-shredding-dreams-steve-vai/
https://www.reddit.com/r/DevinTownsend/comments/17s332s/devin_and_the_vai_years/
https://www.reddit.com/r/DevinTownsend/comments/k9jot4/devin_townsend_i_was_unable_to_articulate_my/
https://www.kerrang.com/devin-townsend-i-was-unable-to-articulate-my-discontent-so-i-tended-to-act-up-i-even-took-a-sh-t-in-steve-vais-guitar-case
https://www.reddit.com/r/DevinTownsend/comments/6tia0r/is_vai_comparing_devin_to_zappa/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants