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

core mode: add version() #35298

Merged
merged 2 commits into from Aug 4, 2021

Conversation

samouri
Copy link
Member

@samouri samouri commented Jul 19, 2021

summary

Adds .version to #core/mode. Removes it from src/internal-version.js.

@samouri samouri force-pushed the mode-internal-runtime-version branch 2 times, most recently from 86542de to 9353008 Compare July 19, 2021 21:02
@samouri samouri self-assigned this Jul 19, 2021
@samouri samouri force-pushed the mode-internal-runtime-version branch from 99f688c to f53e7f6 Compare July 20, 2021 15:20
@samouri samouri requested a review from rcebulko July 20, 2021 15:23
@samouri samouri force-pushed the mode-internal-runtime-version branch from f53e7f6 to 888f342 Compare July 20, 2021 15:25
@samouri samouri requested a review from jridgewell July 20, 2021 16:17
@samouri samouri marked this pull request as ready for review July 20, 2021 16:17
@amp-owners-bot
Copy link

amp-owners-bot bot commented Jul 20, 2021

Hey @jridgewell! These files were changed:

src/core/mode/index.js
src/core/mode/version.js

Copy link
Contributor

@rcebulko rcebulko left a comment

Choose a reason for hiding this comment

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

I know this used to live in mode, but WDYT about moving it into #core/constants? Then again, I suppose the same could be said of all the mode constants, so I'm not sure what makes the most sense. Approving to unblock.

@samouri
Copy link
Member Author

samouri commented Jul 20, 2021

I know this used to live in mode, but WDYT about moving it into #core/constants? Then again, I suppose the same could be said of all the mode constants, so I'm not sure what makes the most sense. Approving to unblock.

What is mode but a set of constants :)

@rcebulko
Copy link
Contributor

I know this used to live in mode, but WDYT about moving it into #core/constants? Then again, I suppose the same could be said of all the mode constants, so I'm not sure what makes the most sense. Approving to unblock.

What is mode but a set of constants :)

Things like minified/esm/fortesting etc are really the "mode" in which it was compiled, whereas the RTV is very much a constant. My feeling is that getMode got overloaded because it became the place to dump compile-time-ish constants, but really I think this could/should just be a const INTERNAL_RTV = "..."; in #core/constants/internal-rtv, and bring mode back to just representing the binary/execution mode

@samouri
Copy link
Member Author

samouri commented Jul 21, 2021

I know this used to live in mode, but WDYT about moving it into #core/constants? Then again, I suppose the same could be said of all the mode constants, so I'm not sure what makes the most sense. Approving to unblock.

What is mode but a set of constants :)

Things like minified/esm/fortesting etc are really the "mode" in which it was compiled, whereas the RTV is very much a constant. My feeling is that getMode got overloaded because it became the place to dump compile-time-ish constants, but really I think this could/should just be a const INTERNAL_RTV = "..."; in #core/constants/internal-rtv, and bring mode back to just representing the binary/execution mode

I'd push back on the concept of "mode it is compiled in". I don't know of a good definition for what constitutes a mode and what doesn't. Instead I'd argue the clean separation of constants exists between build constants vs. source constants.

@rcebulko
Copy link
Contributor

I'd push back on the concept of "mode it is compiled in". I don't know of a good definition for what constitutes a mode and what doesn't. Instead I'd argue the clean separation of constants exists between build constants vs. source constants.

I don't feel strongly enough, this is fine by me 👍🏻

@samouri samouri force-pushed the mode-internal-runtime-version branch from 888f342 to 9e7c915 Compare July 22, 2021 16:50
Copy link
Contributor

@rcebulko rcebulko left a comment

Choose a reason for hiding this comment

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

I'm curious if it would be sensible to rename this to just mode.rtv()? I feel like it's a ubiquitous-enough term that it would be very easily understood

@samouri
Copy link
Member Author

samouri commented Jul 22, 2021

I'm curious if it would be sensible to rename this to just mode.rtv()? I feel like it's a ubiquitous-enough term that it would be very easily understood

I'm fine with that.

Separate note: DCE doesn't seem to be working. I think we can make the amp-mode transform also operate on the namespace import of import * as mode from #core/mode

@rcebulko
Copy link
Contributor

I'm curious if it would be sensible to rename this to just mode.rtv()? I feel like it's a ubiquitous-enough term that it would be very easily understood

I'm fine with that.

Separate note: DCE doesn't seem to be working. I think we can make the amp-mode transform also operate on the namespace import of import * as mode from #core/mode

Working for what? DCE should be working for the true/false values; I don't believe it would inline the RTV string if that's what you're expecting.

@samouri
Copy link
Member Author

samouri commented Jul 30, 2021

I'm curious if it would be sensible to rename this to just mode.rtv()? I feel like it's a ubiquitous-enough term that it would be very easily understood

I'm fine with that.

Separate note: DCE doesn't seem to be working. I think we can make the amp-mode transform also operate on the namespace import of import * as mode from #core/mode

Actually...this isn't rtv(), it is version()...updated accordingly.
Also will update the babel plugin (but split it out to a new PR once it works) so that we can land this without a size regression

@samouri samouri force-pushed the mode-internal-runtime-version branch 3 times, most recently from b42cbf6 to 276aee1 Compare July 30, 2021 18:21
Copy link
Contributor

@rcebulko rcebulko left a comment

Choose a reason for hiding this comment

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

This is great! Thanks for doing it
Side note: I've found it easier to shift logic to core in one PR and have mode.js reference it, then (in theory) eventually update callsites/transforms in a separate PR. If you feel motivated to keep working on these, uses of getMode(win).test, and getMode(win).localDev could both be updated to the core versions as well; I moved the logic to core, but didn't update all the files because of OWNERS approval 😆

@samouri samouri force-pushed the mode-internal-runtime-version branch from 276aee1 to d334977 Compare August 3, 2021 20:25
@samouri samouri force-pushed the mode-internal-runtime-version branch from d334977 to 40eb85e Compare August 3, 2021 21:42
@samouri samouri changed the title core mode: add internalRuntimeVersion core mode: add version() Aug 3, 2021
@samouri samouri merged commit 85ef341 into ampproject:main Aug 4, 2021
@Mstafamhamadmhamad

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants