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

Add support for scalaJSOutputPatterns #2233

Merged
merged 2 commits into from
Jan 5, 2023

Conversation

lolgab
Copy link
Member

@lolgab lolgab commented Jan 4, 2023

Fixes #1721

@lolgab lolgab marked this pull request as ready for review January 4, 2023 23:32
@lolgab lolgab requested a review from lefou January 5, 2023 10:58
Copy link
Member

@lefou lefou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Only one question about visibility.

Comment on lines 112 to 116
private[scalajslib] val jsFile: String,
private[scalajslib] val sourceMapFile: String,
private[scalajslib] val moduleName: String,
private[scalajslib] val jsFileURI: String,
private[scalajslib] val sourceMapURI: String
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these private?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the apply and the withX methods are public, there is no reason to keep these vals non-public.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inspired by Scala.js. This configuration class is meant to be a "write-only", there is no usage on the reading side, that's why I think they make the values package-private here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The apply is private as well

Copy link
Member

@lefou lefou Jan 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just noticed the apply is private, too. Still, I think, if we can create it with some method e.g. withJSFile accepting a String, than there is sooner or later someone who will want to programmatically retrieve that String, e.g. to manipulate it slightly.

If there is no other good reason (as we don't protect use from extra API maintenance here), we should not make it harder than necessary and make it public.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually, I prefer to follow whatever the Scala.js plugin does, but what you said makes sense.
Made them public ✅

Comment on lines +86 to +87
moduleSplitStyle: ModuleSplitStyle, // ignored in 0.6
outputPatterns: OutputPatterns // ignored in 0.6
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes sense to focus on dropping 0.6 support at this point. See #2218.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is meant to go very soon, so we don't want to invest time on it :)

@lolgab lolgab requested a review from lefou January 5, 2023 15:04
@lefou lefou merged commit 5ef7364 into com-lihaoyi:main Jan 5, 2023
@lefou lefou added this to the 0.11.0-M2 milestone Jan 5, 2023
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

Successfully merging this pull request may close these issues.

Support Scala.js linker config OutputPatterns
2 participants