Feature: Add Extension Option to Support Custom Suffixes (useful for ESM builds)

[eberling]

This change adds the option to add suffixes, primarily with file extensions in mind, which is a use case I needed to support ESM builds. Barrels thus accepts a string passed with -x and appends it to all exports.

[BitForger]

Hi @eberling, thanks for the PR.

I have a couple questions that would be great if you could address before any decisions are made. To clarify, I'm clicking request changes but that doesn't necessarily mean you need to change it. Just some clarification first would be great.

My only other request so far would be to remove the yarn.lock file.

Thanks

[eberling]

Hi everyone, thank you for your feedback.

Following Changes:

• Error Handling: anything but a string is accepted (although yargs automatically parses everything as string, so this is just future proofing. Also, passing no arg to -x parses as an empty string if i tested it correctly).
• Improved Usage explanation in README
• Added Tests

In regards to dynamically determining file extensions: I think this is a great idea and could be useful for me in the future as well. I would suggest to provide this option of doing it first, as this already covers some use cases and does not have to provide a guarantee to be able to support all possible types of mappings (although at this point i can only think of .ts and .d.ts that require a mapping , for all other cases such as .mjs and .json you can just leave the original extension).

[eberling]

Hey,
I made the changes. Barrels now dynamically checks the ending and appends the correct extension. the parameter is a boolean and is toggled off per default.

[eberling]

Apologies. If there are any other questions please let me know!

…

On Fri 29. Oct 2021 at 17:36, Noah ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/builder.ts <#174 (comment)>: > @@ -127,8 +133,13 @@ export function buildImportPath( if (directoryPath !== ".") { directoryPath = `.${path.sep}${directoryPath}`; } - // Strip off the .ts or .tsx from the file name. - const fileName = getBasename(relativePath); + + // Strip off the .ts or .tsx from the file name, unless configured otherwise. + const baseName = getBasename(relativePath); + + // Add .js extensions for esm compatibility + const fileName = baseName + extension; Why do you consider it a hack? You are producing valid Typescript code. Using "import from foo.js" is even supported in VSCode and directs you to the .ts file. @eberling <https://github.com/eberling> My understanding was you wanted to run this against compiled output which was what my issue was. Being snippy and not clearly answering questions isn't helping me understand how this is supposed to be used. It appears now that you didn't intend to run it against compiled code, which is good since that is what I was concerned about. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#174 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI6MY4FYNIXNZ3TJHIABQITUJK5RBANCNFSM5FT2OIIQ> .

[BitForger]

Why is there a submodule being added here? Please remove this.

[bencoveney]

I'll be able to have a decent review of all that has been discussed above during next week.

I haven't used ES modules much myself, and it looks like there is still some misunderstandings about the problem were trying to solve (and I will probably have these myself!), so a sample project demonstrating what's happening would still be really helpful, or I can try to reproduce this myself using the information above to get a better understanding.

For the root problem: are we trying to support:

• modifing extensions on imports? or
• ESM project configuration?

They might both have the same symptoms, but the solution might be different in each case.

[BitForger]

@bencoveney ESM projects. It writes the .js extension in the index.ts file so that it properly supports the ESM spec. Reading the way TS 4.5+ is going to work for ESM helps understand the why behind the solution. https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html

[bencoveney]

Thanks! I'll take a look.

…

On Fri, 29 Oct 2021, 17:39 Noah, ***@***.***> wrote: @bencoveney <https://github.com/bencoveney> ESM projects. It writes the .js extension in the index.ts file so that it properly supports the ESM spec. Reading the way TS 4.5+ is going to work for ESM helps understand the why behind the solution. https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#174 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIBGNTSLFB3MU6PRPFRUBLUJLE4NANCNFSM5FT2OIIQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[bencoveney]

Hi @eberling

I have created a sample that I believe represents an ESM solution here: https://github.com/bencoveney/barrelsby/tree/example-esm/examples/esm

I'm continuing to look at the documentation above but if you get chance, it would be great if you could confirm this represents the kind of problem you are seeing.

For reference:

• npm run generate-barrels - to build the barrels, passes okay.
• npm run build - to run the typescript compiler, passes okay.
• npm run run - to run the javascript using node, fails with:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/ben/projects/barrelsby/examples/esm/src/esm-export-default-1' imported from /Users/ben/projects/barrelsby/examples/esm/src/index.js

[hoodie]

let me chime in here for @eberling
Yes this is basically the root of the evil. Because typescript is weird and allows you to leave out the extensions you might end up generating barrels that are not valid javascript.

[bencoveney]

I've written up what I think looks like a reasonable plan for supporting ES Modules on #178. Please have a look at let me know if there is any feedback. I figured an issue (rather than a PR) would be a better place to have that discussion.

Thanks again everyone who has contributed to this so far!

[github-actions]

No activity has been seen recently, marking as stale. If this is a mistake please reach out to a collaborator