ref(build): Turn on `isolatedModules` TS option #4896

lobsterkatie · 2022-04-07T21:11:32Z

Note: This and #4926 are together a (slightly updated) repeat of #4497, to get it onto the main v7 branch.

This applies the TypeScript isolatedModules setting to all packages in the repo, which is necessary in order for us to use any compiler other than tsc. (All other compilers handle each file separately, without understanding the relationships between them the way tsc does, so we need TS to warn us if we're doing anything which would make that a problem).

It also makes two code changes necessary in order to be compatible with the isolatedModules flag, specifically:

All re-exported types and interfaces (anything that will get stripped away when compiling from TS to JS) are now exported using export type. This lets non-tsc compilers know that the exported types are eligible for stripping, in spite of the fact that said compilers can't follow the export path backwards to see the types' implementation.
Usages of the Severity enum from @sentry/types were replaced with string literals, which was necessary here because non-tsc compilers can't trace usages of a const enum back to their underlying values to do the substitution. They therefore leave those usages alone, while at the same time stripping the enum definitions the way tsc would. This leads to usages of something which no longer exists, which is obviously a problem. Using the string literals prevents that. Update: This has been split off into its own PR, linked above.

github-actions · 2022-04-07T22:14:20Z

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	20.12 KB (-0.11% 🔽)
@sentry/browser - ES5 CDN Bundle (minified)	64.17 KB (-0.69% 🔽)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	18.76 KB (-0.54% 🔽)
@sentry/browser - ES6 CDN Bundle (minified)	57.72 KB (-0.43% 🔽)
@sentry/browser - Webpack (gzipped + minified)	23.36 KB (+0.52% 🔺)
@sentry/browser - Webpack (minified)	81.11 KB (-0.74% 🔽)
@sentry/react - Webpack (gzipped + minified)	23.39 KB (+0.5% 🔺)
@sentry/nextjs Client - Webpack (gzipped + minified)	47.85 KB (-0.44% 🔽)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	25.99 KB (-0.31% 🔽)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	24.33 KB (-0.62% 🔽)

AbhiPrasad · 2022-04-07T22:21:49Z

Usages of the Severity enum from @sentry/types were replaced with string literals

Let’s chat about this tomorrow - I think it’s dependent on what we do based on #4888

lobsterkatie · 2022-04-11T23:27:46Z

Usages of the Severity enum from @sentry/types were replaced with string literals

Let’s chat about this tomorrow - I think it’s dependent on what we do based on #4888

UPDATE: We chatted about this IRL, and decided that even though we will likely not remove the Severity type in v7 after all, the changes here related to that deprecation aren't harmful, and will set us up for a future deprecation, so we decided to keep them ~~in this PR~~, though in a separate PR.

AbhiPrasad · 2022-04-12T01:06:46Z

packages/browser/src/eventbuilder.ts

@@ -162,7 +162,7 @@ export function eventFromException(
  const syntheticException = (hint && hint.syntheticException) || undefined;
  const event = eventFromUnknownInput(exception, syntheticException, attachStacktrace);
  addExceptionMechanism(event); // defaults to { type: 'generic', handled: true }
-  event.level = Severity.Error;
+  event.level = 'error' as Severity;


Can we leave a comment near the Severity enum defn about why we have to do this cast everywhere?

I'm wondering now if we shouldn't actually just change the places where Severity is used to accept either a Severity or a SeverityLevel...

UPDATE: Went with the SeverityLevel option, in the linked PR.

Note: This and #4896 are together a (slightly updated) repeat of #4497, to get it onto the main v7 branch. Our original v7 plan called for deprecating and then removing the `Severity` enum which lives in `@sentry/types`, because enums transpile to a two-way lookup function with a fairly hefty footprint (see this SO answer[1] from one of the maintainers of TS). We therefore added a new `SeverityLevel` type, which is the union of all of `Severity`'s underlying values, and directed people to use that instead. Though we subsequently decided not to remove `Severity` (at least in v7), we agreed that we should stop using it internally. This implements that change. Key Changes: - `Severity` and `severityFromString` have been redeprecated. - The original plan to have `SeverityLevel` live in `@sentry/utils` has been reverted, and it now lives only in `@sentry/types`. - The internal `SeverityLevels` array on which we were basing `SeverityLevel` has been removed. While we lose the elegance of the derived type, we gain the ability to truly only export types from `@sentry/types`. - Wherever we accept a `Severity` value, we now also accept a `SeverityLevel`. - All internal uses of `Severity` values have been replaced with the equivalent string constants. - A new `severityLevelFromString` function has been introduced, and is now used in place of `SeverityFromString`. - The tests for `severityFromString` have been cleaned up and replaced with equivalent tests for `SeverityLevelFromString`. [1] https://stackoverflow.com/a/28818850

Note: This and #4926 are together a (slightly updated) repeat of #4497, to get it onto the main v7 branch. This applies [the TypeScript `isolatedModules` setting[1] to all packages in the repo, which is necessary in order for us to use any compiler other than `tsc`. (All other compilers handle each file separately, without understanding the relationships between them the way `tsc` does, so we need TS to warn us if we're doing anything which would make that a problem). It also makes the second of two code changes necessary in order to be compatible with the `isolatedModules` flag: all re-exported types and interfaces (anything that will get stripped away when compiling from TS to JS) are now exported using `export type`. This lets non-`tsc` compilers know that the exported types are eligible for stripping, in spite of the fact that said compilers can't follow the export path backwards to see the types' implementation. (The other code change, eliminating our usage of the `Severity` enum, was split off into the PR linked above.) [1] https://www.typescriptlang.org/tsconfig#isolatedModules

Note: This and #4896 are together a (slightly updated) repeat of #4497, to get it onto the main v7 branch. Our original v7 plan called for deprecating and then removing the `Severity` enum which lives in `@sentry/types`, because enums transpile to a two-way lookup function with a fairly hefty footprint (see this SO answer[1] from one of the maintainers of TS). We therefore added a new `SeverityLevel` type, which is the union of all of `Severity`'s underlying values, and directed people to use that instead. Though we subsequently decided not to remove `Severity` (at least in v7), we agreed that we should stop using it internally. This implements that change. Key Changes: - `Severity` and `severityFromString` have been redeprecated. - The original plan to have `SeverityLevel` live in `@sentry/utils` has been reverted, and it now lives only in `@sentry/types`. - The internal `SeverityLevels` array on which we were basing `SeverityLevel` has been removed. While we lose the elegance of the derived type, we gain the ability to truly only export types from `@sentry/types`. - Wherever we accept a `Severity` value, we now also accept a `SeverityLevel`. - All internal uses of `Severity` values have been replaced with the equivalent string constants. - A new `severityLevelFromString` function has been introduced, and is now used in place of `SeverityFromString`. - The tests for `severityFromString` have been cleaned up and replaced with equivalent tests for `SeverityLevelFromString`. [1] https://stackoverflow.com/a/28818850

Note: This and #4926 are together a (slightly updated) repeat of #4497, to get it onto the main v7 branch. This applies [the TypeScript `isolatedModules` setting[1] to all packages in the repo, which is necessary in order for us to use any compiler other than `tsc`. (All other compilers handle each file separately, without understanding the relationships between them the way `tsc` does, so we need TS to warn us if we're doing anything which would make that a problem). It also makes the second of two code changes necessary in order to be compatible with the `isolatedModules` flag: all re-exported types and interfaces (anything that will get stripped away when compiling from TS to JS) are now exported using `export type`. This lets non-`tsc` compilers know that the exported types are eligible for stripping, in spite of the fact that said compilers can't follow the export path backwards to see the types' implementation. (The other code change, eliminating our usage of the `Severity` enum, was split off into the PR linked above.) [1] https://www.typescriptlang.org/tsconfig#isolatedModules

Note: This and #4896 are together a (slightly updated) repeat of #4497, to get it onto the main v7 branch. Our original v7 plan called for deprecating and then removing the `Severity` enum which lives in `@sentry/types`, because enums transpile to a two-way lookup function with a fairly hefty footprint (see this SO answer[1] from one of the maintainers of TS). We therefore added a new `SeverityLevel` type, which is the union of all of `Severity`'s underlying values, and directed people to use that instead. Though we subsequently decided not to remove `Severity` (at least in v7), we agreed that we should stop using it internally. This implements that change. Key Changes: - `Severity` and `severityFromString` have been redeprecated. - The original plan to have `SeverityLevel` live in `@sentry/utils` has been reverted, and it now lives only in `@sentry/types`. - The internal `SeverityLevels` array on which we were basing `SeverityLevel` has been removed. While we lose the elegance of the derived type, we gain the ability to truly only export types from `@sentry/types`. - Wherever we accept a `Severity` value, we now also accept a `SeverityLevel`. - All internal uses of `Severity` values have been replaced with the equivalent string constants. - A new `severityLevelFromString` function has been introduced, and is now used in place of `SeverityFromString`. - The tests for `severityFromString` have been cleaned up and replaced with equivalent tests for `SeverityLevelFromString`. [1] https://stackoverflow.com/a/28818850

Note: This and #4926 are together a (slightly updated) repeat of #4497, to get it onto the main v7 branch. This applies [the TypeScript `isolatedModules` setting[1] to all packages in the repo, which is necessary in order for us to use any compiler other than `tsc`. (All other compilers handle each file separately, without understanding the relationships between them the way `tsc` does, so we need TS to warn us if we're doing anything which would make that a problem). It also makes the second of two code changes necessary in order to be compatible with the `isolatedModules` flag: all re-exported types and interfaces (anything that will get stripped away when compiling from TS to JS) are now exported using `export type`. This lets non-`tsc` compilers know that the exported types are eligible for stripping, in spite of the fact that said compilers can't follow the export path backwards to see the types' implementation. (The other code change, eliminating our usage of the `Severity` enum, was split off into the PR linked above.) [1] https://www.typescriptlang.org/tsconfig#isolatedModules

Note: This and #4896 are together a (slightly updated) repeat of #4497, to get it onto the main v7 branch. Our original v7 plan called for deprecating and then removing the `Severity` enum which lives in `@sentry/types`, because enums transpile to a two-way lookup function with a fairly hefty footprint (see this SO answer[1] from one of the maintainers of TS). We therefore added a new `SeverityLevel` type, which is the union of all of `Severity`'s underlying values, and directed people to use that instead. Though we subsequently decided not to remove `Severity` (at least in v7), we agreed that we should stop using it internally. This implements that change. Key Changes: - `Severity` and `severityFromString` have been redeprecated. - The original plan to have `SeverityLevel` live in `@sentry/utils` has been reverted, and it now lives only in `@sentry/types`. - The internal `SeverityLevels` array on which we were basing `SeverityLevel` has been removed. While we lose the elegance of the derived type, we gain the ability to truly only export types from `@sentry/types`. - Wherever we accept a `Severity` value, we now also accept a `SeverityLevel`. - All internal uses of `Severity` values have been replaced with the equivalent string constants. - A new `severityLevelFromString` function has been introduced, and is now used in place of `SeverityFromString`. - The tests for `severityFromString` have been cleaned up and replaced with equivalent tests for `SeverityLevelFromString`. [1] https://stackoverflow.com/a/28818850

Note: This and #4926 are together a (slightly updated) repeat of #4497, to get it onto the main v7 branch. This applies [the TypeScript `isolatedModules` setting[1] to all packages in the repo, which is necessary in order for us to use any compiler other than `tsc`. (All other compilers handle each file separately, without understanding the relationships between them the way `tsc` does, so we need TS to warn us if we're doing anything which would make that a problem). It also makes the second of two code changes necessary in order to be compatible with the `isolatedModules` flag: all re-exported types and interfaces (anything that will get stripped away when compiling from TS to JS) are now exported using `export type`. This lets non-`tsc` compilers know that the exported types are eligible for stripping, in spite of the fact that said compilers can't follow the export path backwards to see the types' implementation. (The other code change, eliminating our usage of the `Severity` enum, was split off into the PR linked above.) [1] https://www.typescriptlang.org/tsconfig#isolatedModules

lobsterkatie changed the base branch from master to 7.x April 7, 2022 21:11

lobsterkatie force-pushed the kmclb-use-isolated-modules branch 2 times, most recently from 376b05a to 28983aa Compare April 7, 2022 21:56

lobsterkatie force-pushed the 7.x branch from 81b10fb to 9d29071 Compare April 7, 2022 22:02

lobsterkatie force-pushed the kmclb-use-isolated-modules branch from 28983aa to 66d6d04 Compare April 7, 2022 22:08

lobsterkatie force-pushed the kmclb-use-isolated-modules branch from 66d6d04 to 2aa2bb5 Compare April 11, 2022 06:48

AbhiPrasad added this to the 7.0.0 milestone Apr 11, 2022

lobsterkatie force-pushed the kmclb-use-isolated-modules branch from 2aa2bb5 to 13770bf Compare April 11, 2022 23:28

lobsterkatie marked this pull request as ready for review April 11, 2022 23:52

lobsterkatie requested review from AbhiPrasad, lforst and Lms24 April 11, 2022 23:52

AbhiPrasad approved these changes Apr 12, 2022

View reviewed changes

lobsterkatie force-pushed the kmclb-use-isolated-modules branch from 13770bf to 5bdc22c Compare April 13, 2022 05:12

lobsterkatie mentioned this pull request Apr 13, 2022

ref(types): Stop using Severity enum #4926

Merged

lobsterkatie added 2 commits April 13, 2022 17:36

turn isolatedModules on in main tsconfig

3d5dfe9

use export type when re-exporting types

40b5832

lobsterkatie force-pushed the kmclb-use-isolated-modules branch from 5bdc22c to 40b5832 Compare April 14, 2022 00:38

lobsterkatie merged commit 5fa71bb into 7.x Apr 14, 2022

lobsterkatie deleted the kmclb-use-isolated-modules branch April 14, 2022 01:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ref(build): Turn on `isolatedModules` TS option #4896

ref(build): Turn on `isolatedModules` TS option #4896

lobsterkatie commented Apr 7, 2022 •

edited

Loading

github-actions bot commented Apr 7, 2022 •

edited

Loading

AbhiPrasad commented Apr 7, 2022

lobsterkatie commented Apr 11, 2022 •

edited

Loading

AbhiPrasad Apr 12, 2022

lobsterkatie Apr 12, 2022 •

edited

Loading

ref(build): Turn on isolatedModules TS option #4896

ref(build): Turn on isolatedModules TS option #4896

Conversation

lobsterkatie commented Apr 7, 2022 • edited Loading

github-actions bot commented Apr 7, 2022 • edited Loading

size-limit report 📦

AbhiPrasad commented Apr 7, 2022

lobsterkatie commented Apr 11, 2022 • edited Loading

AbhiPrasad Apr 12, 2022

Choose a reason for hiding this comment

lobsterkatie Apr 12, 2022 • edited Loading

Choose a reason for hiding this comment

ref(build): Turn on `isolatedModules` TS option #4896

ref(build): Turn on `isolatedModules` TS option #4896

lobsterkatie commented Apr 7, 2022 •

edited

Loading

github-actions bot commented Apr 7, 2022 •

edited

Loading

lobsterkatie commented Apr 11, 2022 •

edited

Loading

lobsterkatie Apr 12, 2022 •

edited

Loading