# Proposal: \`RuntimeSupport.{ navigator(), import.mata() }\`

**URL:** <https://es.discourse.group/t/proposal-runtimesupport-navigator-import-mata/2033>\
**Category:** 💡 Ideas\
**Tags:** proposal\
**Created:** [May 6, 2024, 1:12pm UTC](https://es.discourse.group/t/proposal-runtimesupport-navigator-import-mata/2033 "2024-05-06T13:12:35Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![hmidmrii](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/hmidmrii/32/2083_2.png) [@hmidmrii](https://es.discourse.group/u/hmidmrii)\
**Post date:** [May 6, 2024, 1:12pm UTC](https://es.discourse.group/t/proposal-runtimesupport-navigator-import-mata/2033/1 "2024-05-06T13:12:35Z")

</div>

I think one of the pain points when you write code, that sometimes you try to do stuff that are not supported in the current runtime (node, browser, bun, ...), or maybe looking for an ECMA feature and you need to know if it's supported,

it would be great if we can have a class that can tell us if a certain thing implemented or not, it would be great.

a good usage would be:

```javascript
let url; 
if(RuntimeSupport.import.meta.url())
  url = import.meta.url;
else
  url = document.currentScript.src;

```

where `RuntimeSupport` could be implemented like this:

```javascript

// This will be provided by the runtime, and maybe later extended by polyfills
const RuntimeSupportedFeatures = {
  import: {
    meta: {
      dirname: true,
      filename: true,
      url: true,
      resolve: true,
    },
  },
};

/**@return {ProxyHandler} */
const getHandler = (keys = []) => ({
  get: (_, key) => {
    return new Proxy(() => {}, getHandler([...keys, key]));
  },
  apply: () => {
    let value = RuntimeSupportedFeatures;

    for (let index = 0; index < keys.length; index++) {
      if (!value) return false;

      const key = keys[index];

      value = value[key];
    }

    return !!value;
  },
});

var RuntimeSupport = new Proxy({}, getHandler());

```

for sure we have smarter people than me that can figure out a better API or implementation, but that what I thought of

---

<div class="post-metadata">

**Author:** ![bergus](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/bergus/32/152_2.png) [@bergus](https://es.discourse.group/u/bergus)\
**Post date:** [May 6, 2024, 11:18pm UTC](https://es.discourse.group/t/proposal-runtimesupport-navigator-import-mata/2033/2 "2024-05-06T23:18:30Z")

</div>

Why not just use normal feature detection? In your case, that would be `"url" in import.meta`.

Or

```javascript
const url = import.meta.url ?? document.currentScript.src;

```

---

<div class="post-metadata">

**Author:** ![hmidmrii](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/hmidmrii/32/2083_2.png) [@hmidmrii](https://es.discourse.group/u/hmidmrii)\
**Post date:** [May 7, 2024, 5:43am UTC](https://es.discourse.group/t/proposal-runtimesupport-navigator-import-mata/2033/3 "2024-05-07T05:43:34Z")

</div>

@bergus some times certain features will throw an error when you try to access it in different runtimes, for instance try to check if `import` is present using `typeof import === 'undefined'` in a CJS node environment it will throw an error for just having this `import` keyword, but for bun you can use `require` and `import` at the same time, and we don't know what new runtimes will do in such or different cases, it might be good if all of them provided a way to check before use

---

<div class="post-metadata">

**Author:** ![ljharb](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/ljharb/32/8_2.png) [@ljharb](https://es.discourse.group/u/ljharb)\
**Post date:** [May 7, 2024, 5:57am UTC](https://es.discourse.group/t/proposal-runtimesupport-navigator-import-mata/2033/4 "2024-05-07T05:57:46Z")

</div>

The Script and Module parse goals are ambiguous, so you simply can't consistently make a file that works in both - you have to use the file extension, generally, to indicate what format it is, and you can only execute it with the format it was intended for.

---

<div class="post-metadata">

**Author:** ![hmidmrii](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/hmidmrii/32/2083_2.png) [@hmidmrii](https://es.discourse.group/u/hmidmrii)\
**Post date:** [May 7, 2024, 7:02am UTC](https://es.discourse.group/t/proposal-runtimesupport-navigator-import-mata/2033/5 "2024-05-07T07:02:17Z")

</div>

@ljharb Yes you might be right, but the proposal is more than only `import` and `require`, it's about the new features that may and may not be included in certain runtime

---

<div class="post-metadata">

**Author:** ![dmchurch](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/dmchurch/32/1962_2.png) [@dmchurch](https://es.discourse.group/u/dmchurch)\
**Post date:** [May 8, 2024, 2:12am UTC](https://es.discourse.group/t/proposal-runtimesupport-navigator-import-mata/2033/6 "2024-05-08T02:12:11Z")

</div>

> [@ljharb](#):
>
> The Script and Module parse goals are ambiguous, so you simply can't consistently make a file that works in both

Not for nothing, but this is very much the driving use case behind [Parser Augmentation](https://es.discourse.group/t/proposal-parser-augmentation-mechanism/2008). Syntactic language features can't be polyfilled _or even tested for_, which means your options as a developer are (a) don't use the new features, (b) consign yourself to always having to transpile your code, or (c) don't support older engines. Even a PA implementation that _doesn't_ support runtime syntax polyfills (in other words, one with a static parser) provides a way for the source text to ask the parser what syntax features are available - you could use it in a similar sort of way as C's `#ifdef` directive. You could write a single file that parses correctly both as a CJS script using `require` and `module.exports` and also as an ES module using `import` and `export`, just by including `syntax` directives to guard the contextually-invalid syntax from the runtime parser.

Of course, this only works if the PA syntax itself is old enough that it's part of the ecosystem baseline, which tends to take around a decade or so. That's why it's so valuable to get it added to the ECMA262 spec _now_ - it might only get minimal runtime support in the near-term, but ten years down the line you'll have an answer for "how do I write a file that supports different versions/variants of ECMAScript syntax?"

---

<div class="post-metadata">

**Author:** ![shaedrich](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/shaedrich/32/704_2.png) [@shaedrich](https://es.discourse.group/u/shaedrich)\
**Post date:** [November 18, 2024, 4:12pm UTC](https://es.discourse.group/t/proposal-runtimesupport-navigator-import-mata/2033/7 "2024-11-18T16:12:05Z")

</div>

That seems to have some similarily with CSS's [`@supports`](https://developer.mozilla.org/en-US/docs/Web/CSS/@supports) rule:

```javascript
@supports (import.meta.url) { // similar to try catch and the blocks for const/let
  const url = import.meta.url;
  // …
}

```

or:

```javascript
let url;
if (Runtime.supports(import.meta.url) {
  url = import.meta.url;
} else {
  url = document.currentScript.src;
}

```

but probably, this could be a string:

```javascript
let url;
if (Runtime.supports('import-meta-url') { // other languages would probably use enums here
  url = import.meta.url;
} else {
  url = document.currentScript.src;
}

```