打字稿const枚举替代

发布于 2025-01-21 15:18:47 字数 1025 浏览 4 评论 0原文

越来越多的现代打字稿转介剂已朝着每模块转卸策略迈进,从而大大提高了构建速度,但消除了交叉模块const enum用法的可能性,因为它们需要类型信息。

我有一个大量 const enums,当使用const提供的情况下使用时,

  1. 即使是由于长属性名称
  2. 不想公开

泄漏内部,后端属性名称,我现在 ,我拥有这些const enum定义从后端本机代码生成的自动定义。作为一个人为的例子,您可以想象我在Apple工作,并拥有每个硬件设备的大量枚举。

const enum HardwareType {
    Apple1 = 0,
    // ...
    iPhoneX = 412,
    // ...
    iPhoneUltraXD = 499, // Some theoretical unannounced iPhone
}

如果我只是将const enum hardwareType更改为枚举hardwareType,除了增加我的捆绑包大小外,我现在还将新的“ iPhone ultra XD”泄露给公众。

我看到类似Terser 支持- -mangle-props选项,但即使在官方文档中也要警告,这也意味着创建一个涵盖每一个HardwareType的正则是吗?更不用说这只是我人为的例子,我在现实中拥有数百个价值观。

我真的想将最新技术用于应用程序捆绑,但是在编译时间内的恒定价值内,是否真的没有更好的选择?

More and more modern Typescript transpilers have moved toward a strategy of per-module transpilation, which significantly increases build speed, but eliminates the possibility for cross-module const enum usage, since transpilation of them requires type information.

I have a significant amount of const enums that when used without the inlining that const provides:

  1. End up being hundreds of KBs even after minification due to long property names
  2. Leak internal, backend property names that I don't want public

Right now I have these const enum definitions auto generated from backend native code. As a contrived example, you can imagine I work at Apple and have a great big const enum of every hardware device.

const enum HardwareType {
    Apple1 = 0,
    // ...
    iPhoneX = 412,
    // ...
    iPhoneUltraXD = 499, // Some theoretical unannounced iPhone
}

If I just change const enum HardwareType to enum HardwareType, in addition to bumping up my bundle size, I've now leaked the new "iPhone Ultra XD" to the public.

I see that something like Terser supports the --mangle-props option, but even that seems to be warned against in the official docs and also would mean creating a regex that covers every single HardwareType? Not to mention that's just my contrived example and I have dozens of these enums in reality with hundreds of values.

I'd really like to use the latest tech for application bundling, but is there really not a better option out there for compile time inlining of constant values?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

故事灯 2025-01-28 15:18:47

const Enum在隐藏原始名称时不是很安全。如您所见,您可以在该操场打字稿编译器在注释中添加了原始名称:

// Input:
const enum Fruites {
    Apple = 1,
    Banana = 2
}

const x = Fruites.Apple
const y = Fruites.Banana

// Output:
"use strict";
const x = 1 /* Apple */;
const y = 2 /* Banana */;

如果您真的很想使用最新技术将应用程序捆绑并想从输出文件中隐藏一些秘密名称,请尝试使用 esbuild-loader esbuild 本身。它支持 define 选项,该选项允许您替换一些秘密命名,并在编译时间中以无意义的值替换为无意义的值that

define: {
  "secrets.hardwareType.iPhoneUltraXD": "499"
}

and safely use the defined value in source code

// Source code: 
if (deviceId === secrets.hardwareType.iPhoneUltraXD) {
// Bundled code:
if(deviceId===499){

define option could be initiated in webpack or esbuild config file with any computed values (even with required json files) so you have no limit in count of compile-time定义。

const enum is not very secure in hiding original names. As you can see in that playground typescript compiler adds original names in comments:

// Input:
const enum Fruites {
    Apple = 1,
    Banana = 2
}

const x = Fruites.Apple
const y = Fruites.Banana

// Output:
"use strict";
const x = 1 /* Apple */;
const y = 2 /* Banana */;

If your a really wondering to use the latest tech for application bundling and want to hide some secret names from output files, try to use esbuild-loader or esbuild itself. It support define option that allows you to replace some secret naming with meaningless values in compilation time like that

define: {
  "secrets.hardwareType.iPhoneUltraXD": "499"
}

and safely use the defined value in source code

// Source code: 
if (deviceId === secrets.hardwareType.iPhoneUltraXD) {
// Bundled code:
if(deviceId===499){

define option could be initiated in webpack or esbuild config file with any computed values (even with required json files) so you have no limit in count of compile-time definitions.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文