I'm a English learner. I would be happy to correct my expression if someone willing to remind me.

I don't see any tractable way to square this circle. import type needs to mean "don't include the value side"; that's its definition. And import { ConstEnum } from 'x' needs to do at least as much importing as import { } from'x' to maintain the definition of import. const enum and import type just aren't really compatible features and I'd advise to avoid const enum in module positions for this reason.

Talking offline with @andrewbranch, this does seem like something where we could just ignore the warning we "should" issue when a value reference occurs. This would still break the transpile scenarios that import type is designed for, but obviously you're not doing that anyway

I think we can look at this problem in a different way. Let's review the scenario in which importsNotUsedAsValues was proposed. Programmers complain that they must write import "someModule"; again to ensure that modules with side effects are imported, otherwise the import may be automatically filtered out.

Then the import type syntax was invented, which can clearly tell the compiler which imports are just TS level and and which imports must be actually written to JS files. That is the key point. We usually only regard the type system as TS level things. Once the value side is involved, we think it is JS level. But in fact, there are still some incoherent things like const enum. It is like constexpr in C++, which is on the value side but will be determined at compile time.

So, I think we only need to change the definition of import type slightly, not as statements that only import types, but as import (something only related to )type(script), then everything can be explained, of course, import type can import values.

That is a pretty good description of how import type already works, but we don’t recognize const enum usage in value space as an allowable usage. It would be possible to add it as an exception, since it doesn’t require a reference to the symbol in JS emit. In fact, I believe @ajafff suggested this early on (#36003). We opted to wait and see if there was demand for it. So far, the demand has been very low (this is the first request since @ajafff’s, as far as I know), but the downsides of implementing it seem small.

Since you are gauging demand for it, we are also running into this in the Azure Portal. We have a ton of dynamically loaded modules (where import type is useful) and use const enums a lot. We have to workaround this issue with non-ideal approaches that could lead to someone mistakenly importing a module explicitly and causing tons of bundling side-effects

As an additional data point, I'm investigating adopting Vite as a dev build tool for Outlook. However, it builds each module individually, so I need to enable "isolatedModules": "true" to ensure the dev build doesn't result in runtime errors. Between this issue and #37774 (some of our dependencies use const enum with "preserveConstEnum": "true", which I cannot control), I cannot enable isolatedModules in the main build.

Adding this ability would really benefit us where I work at as well.

Just adding a datapoint here as well. Our project makes extensive use of a large number of enums in a dependency, and this is directly impeding our efforts to bundle-split that dependency until it's actually needed, instead of just being needed to grab a constant string.

I am in a similar boat where our types come from an extremely large auto-generated package (60mb+ of JS, 8mb of types). I can use import type to import pure types without impacting bundle size, but that completely excludes us from being able to use the enums defined in the types file. Also because default typescript enums are not type safe due to simply being type number (#32690, #36756), there is no possible way to safely use the imported enum type.

// ERROR: 'Foo' cannot be used as a value because it was imported using 'import type'.
const fooSomeValue = Foo.SOME_VALUE;

// This provides zero type safety. Any number could be assigned as a value here.
const fooSomeValue: Foo.SOME_VALUE = 1;

Here is a novel workaround I came up with. Be aware that this is hacky and may not be to your personal tastes, but just posting in order to share.

// Suppose this enum was imported using `import type` and thus we cannot directly use it as a value
enum TestEnum {
  FOO = "FOO",
  BAR = "BAR",
  BAZ = "BAZ",
}

/**
 * Due to https://github.com/microsoft/TypeScript/issues/40344, we cannot declare an object that uses
 * TestEnum as a value, like so
 * {
 *   a: TestEnum.FOO,
 *   b: TestEnum.BAR
 *   ...
 * }
 *
 * So instead, lets make an exhaustive map of the enum type, which is the opposite of the desired mapping
 * above. A compiler error will be thrown if any values are added/removed from TestEnum, so we can ensure
 * we are somewhat type safe here.
 */
const initialMap: Record<TestEnum, string> = {
  FOO: "a",
  BAR: "b",
  BAZ: "c",
};

/**
 * Now, invert that mapping so we now have a map of the your type to enum values, which emulates using
 * the enum as a value.
 */
const invertedMap: Record<string, TestEnum> = Object.keys(initialMap).reduce((res, key) => {
  // We have to ignore the typescript error here as we are definitely doing some janky stuff
  // @ts-ignore
  res[initialMap[key]] = key;
  return res;
}, {} as Record<string, TestEnum>);

// Tada! We have a mapping of string to enum value while only using the enum as a type rather than a value
console.log(invertedMap["b"]); // Logs: 'BAR'

// NOTE: This works well for string enums, but number enums will have their values cast to strings by `Object.keys`
// You could `parseInt()` on these at your own risk...

Do you need ambient const enums (e.g. const enums in .d.ts files) or would a non-const enum work as well?

1. Fundamentally ambient const enums (values -- types are fine) are incompatible with isolatedModules.
2. If isolatedModules is false, you can use ambient const enum values but can't use type-only const enum values (regardless). Is this inconsistent? Are there other self-contained ambient values (entities without .js implementations, necessarily)? Design Meeting Notes, 2/24/2021 #42991 (comment)

My take:

• Ambient const enums are incompatible with isolatedModules and should therefore be avoided.
• Ambient non-const enums are fine (e.g. plain enums in .d.ts files), as are non-ambient const enums (e.g. const enums in .ts files), however tsc --declaration turns non-ambient const enums into ambient const enums: isolatedModules doesn't respect enabled preserveConstEnum option what the project might be build with #37774
• The compiler could instead turn non-ambient const enums into ambient non-const enums, if isolatedModules/preserveConstEnums are true, (isolatedModules doesn't respect enabled preserveConstEnum option what the project might be build with #37774 (comment)) but then what's the difference between that and just using non-const enums in the first place, banning const enums with a linter vs. disarming them with the compiler?
• Avoiding ambient const enums sidesteps the issue of type-only const enum value usage (the current issue, Allow importing both type entity and value entity for "const enum" through "import type" #40344).