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

Release 1.83.1 #1058

Merged
merged 6 commits into from
Jan 27, 2023
Merged

Release 1.83.1 #1058

merged 6 commits into from
Jan 27, 2023

Conversation

odlbot
Copy link
Contributor

@odlbot odlbot commented Jan 25, 2023

Chris Chudzicki

Abdurrehman

Carey P Gumaer

tldr: Changing `module` config changes the syntax used to import/export in the compiled code. The new value, "ES6", means that the code compiled by TS will include import/export statements. That code is then further compiled by Webpack, which removes the imports/exports during concatenation.

Using ES6 import/exports in the typescript output improves Webpack's tree-shaking. (Or really...enables it. I believe webpack does not treeshake unless the input uses ES6 import/export syntax.)

Related:

TS has several sort of settings related to the syntax used in output:

- `lib`: determines the default/builtin type definitions that are included when typechecking your code.
- `target`: Spcecies environment in which your code is going to run, and controls how Typescript downlevels your code.

    > "The `target` setting changes which JS features are downleveled and which are left intact. For example, an arrow function `() => this` will be turned into an equivalent function expression if target is ES5 or lower."

    `target` determines the default value of `lib`. If `target` is ES5, you probably want `lib` to be ES5, too, unless you're doing further transpilation with another tool (like babel).
- `module`: Determines the syntax used for exports.
- `moduleResolution` determines how module identifiers ("some/thing" in  like `import x from "some/thing"`) are interpretted.
* refactor: old course theme removed

* removed some old course theme files from base theme
Nanogallery2 includes hammerjs, screenfull, shifty, and images loaded as modules embedded in its source code; see https://github.com/nanostudio-org/nanogallery2/blob/d6056652705360e19ab330095f489f438a9e9d1c/src/jquery.nanogallery2.core.js#L11-L15.

In browsers, Nanogallery2 intends to expose those objects on the global Window.

However, bundling with Webpack messes up the way Nanogallery2 exposes those objects. (NG checks if `exports` is undefined, but Webpack defines an `eports` object itself.) Consequently, naive inclusion of Nanogallery2 in a webpack build does not work.

To work around this, we previously were including those 4 dependencies separately and manually attaching them to global Window object, which is the workaround suggested at nanostudio-org/nanogallery2#98 (comment).

This approach has several downsides, e.g:  extra js; need to make sure we are including the correct versions of the 4 dependencies.

A cleaner approach is to use imports-loader, as suggested nanostudio-org/nanogallery2#98 (comment).
@github-actions
Copy link

@github-actions
Copy link

Lighthouse results:

results for https://ocw-hugo-themes-www-pr-1058--ocw-next.netlify.app/:

Accessibility Best Practices Performance Progressive Web App SEO
100 💯 83 😄 51 😟 20 😱 79 🙂

results for https://ocw-hugo-themes-www-pr-1058--ocw-next.netlify.app/search/:

Accessibility Best Practices Performance Progressive Web App SEO
93 🎉 92 🎉 70 🙂 30 😰 93 🎉

results for https://ocw-hugo-themes-course-v2-pr-1058--ocw-next.netlify.app/:

Accessibility Best Practices Performance Progressive Web App SEO
80 😄 92 🎉 72 🙂 30 😰 76 🙂

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.

4 participants