@rescript/runtime dependency problems

1

Can we make runtime@12 rc or stable? i have to do pnpm add @rescript/runtime@ci to match the 12.0 release now

2

good catch @xfcw! Itā€™s now listed as latest and should be kept in sync in the future.

Iā€™m curious, what do you use @rescript/runtime for?

1 Like
3

isnā€™t @rescript/runtime required now that it was separated from rescript? I tend to do have rescript under devDependencies and @rescript/runtime under dependencies. if I try to build my monorepo after removing it from one of the projects:

ā€œRollup failed to resolve import ā€œ@rescript/runtime/lib/es6/Stdlib.jsā€ fromā€¦ā€

4

No no, just use rescript as a dependency like before and itā€™ll work! Direct use of @rescript/runtime is meant for people developing libraries that are meant to be consumed by js/ts users, this way the final users donā€™t have to depend on the whole compiler package.

2 Likes
5

Are you using isolated installs with your package manager?

How does your setup roughly look like?

6

really? it literally wonā€™t build without it. itā€™s a pnpm monorepo, one is a lib and one is an app that uses the lib, both are rescript 12

7

itā€™s actually vite that fails, the others seem to build fine

[vite]: Rollup failed to resolve import ā€œ@rescript/runtime/lib/es6/Stdlib.jsā€ from ā€œā€¦/packages/app/src/somefile.resā€

8

heh, no, esbuild fails as well:

getting tons of these:

āœ˜ [ERROR] Could not resolve "@rescript/runtime/lib/es6/Stdlib_Option.js"

    lib/es6/src/foundation/foundation_duration.res.js:3:31:
      3 ā”‚ import * as Stdlib_Option from "@rescript/runtime/lib/es6/Stdlib_Option.js";
        ā•µ                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@rescript/runtime/lib/es6/Stdlib_Option.js" as external to exclude it from
  the bundle, which will remove this error and leave the unresolved path in the bundle.

āœ˜ [ERROR] Could not resolve "@rescript/runtime/lib/es6/Primitive_exceptions.js"

    lib/es6/src/foundation/foundation_duration.res.js:4:38:
      4 ā”‚ import * as Primitive_exceptions from "@rescript/runtime/lib/es6/Primitive_exceptions.js";
        ā•µ                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@rescript/runtime/lib/es6/Primitive_exceptions.js" as external to exclude
  it from the bundle, which will remove this error and leave the unresolved path in the bundle.
9

I recently had a similar thing with bun isolated installs.
The runtime wasnā€™t found by vite and I had to work around that.
Can you create a new discussion for this? That feels like worth talking more in depth about.
We should probably not hijack this thread for that.

2 Likes
10

Moved the posts here into a separate topic.

It should work now:

pnpm info rescript dependencies
{ '@rescript/runtime': '12.0.0' }

pnpm info rescript optionalDependencies
{
  '@rescript/linux-x64': '12.0.0',
  '@rescript/win32-x64': '12.0.0',
  '@rescript/darwin-x64': '12.0.0',
  '@rescript/linux-arm64': '12.0.0',
  '@rescript/darwin-arm64': '12.0.0'
}
1 Like
11

i donā€™t know what you mean when you say ā€œit should work nowā€. your commands give the same output for me, but it still doesnā€™t build/bundle unless i have @rescript/runtime. is this a pnpm-related issue?

12

Sorry, I should have written ā€œif the missing npm tag was actually the issue, it should work now to install without explicitly adding @rescript/runtimeā€.

Whatā€™s actually the issue is hard to say without a repro.

13

maybe the issue is i have rescript under devDeps? which i thiink SHOULD be right but maybe isnā€™t? the tooling is conceptually for devDeps

14

That sounds like it.

We suggest on the installation page to do a normal install:

Mainly because of the runtime.

1 Like
15

Since rescript includes the runtime, it should be a regular dependency.

16

i donā€™t agree with this. since the runtime was actually separated, the right thing to do is keep rescript under devDeps and runtime under deps. thereā€™s zero reason to install tooling in a deployed production environment, you only need the runtime. the right suggestion would be to do what i already do, definitely. the docs should be changed to reflect this.

1 Like
17

The compiler got split per platform so it doesnā€™t add too much weight and if your project is very size sensitive, you probably use a tree shaker anyway! So Iā€™d say the recommended setup is simple and does suit most requirements, but of course you can also use your setup which is correct too!