I'm trying to mocking REST API and import rest namespace for this:
import { rest } from 'msw'
But when checking the types (built-in in the Vue CLI), an error occurs:
ERROR in [project-path]/node_modules/msw/lib/index.d.ts
3:10 String literal expected.
1 | export { composeMocks } from './composeMocks';
2 | export { MockedResponse, ResponseTransformer, response } from './response';
> 3 | export * as context from './context';
| ^
4 | export * from './handlers/requestHandler';
5 | export { default as rest, restContext, RESTMethods } from './handlers/rest';
6 | export { default as graphql, graphqlContext } from './handlers/graphql';
I use TypeScript 3.7
Hey, @tryfonkov. Thanks for raising this. Looks like TypeScript cannot handle the wildcard export on the usage side. I wonder why this never throws during the development/consumption during tests.
I will look into this to make sure you can use the library without TypeScript errors.
I was trying to reproduce this issue using the latest Vue packages, but couldn't. See the steps I've performed below for reference.
yarn global add @vue/cli @vue/cli-service-global.vue create vue-mswyarn add msw.yarn add -D @types/cookie. This raised TypeScript violations, saying that msw uses the cookie package, but my app didn't have any @types/cookie installed. That's the first time I see such behavior, and I wonder if msw should list @types/cookie in dependencies instead of devDependencies.npx msw init public.import { composeMocks, rest } from "msw"
const { start } = composeMocks(
rest.get("/user", (req, res, ctx) => {
return res(ctx.json({ firstName: "John" }))
})
)
start()
After that I've imported my mocks.ts in main.ts:
// src/main.ts
import './mocks'
And then I run yarn serve to serve the app. This is the process stdout after running the "serve" command:
DONE Compiled successfully in 25ms 11:50:45 AM
Type checking in progress...
App running at:
- Local: http://localhost:8080/
- Network: http://192.168.0.122:8080/
No type errors found
Version: typescript 3.8.3
Time: 419ms
When navigated to the spawned host, this is the application's state I see:

@tryfonkov, could you please share with me your application's setup, so I could look into this issue being in the same context? Also, if you have time, could you look at the steps I performed? Perhaps you'll spot some deviation that may help us to fix this issue.
Thank you.
I attempted to create a React + TS codesandbox but was unable to run the npx msw init ./public command so I'm not sure if it's valid. I added the file that was generated from running that command on my local machine but I'm not sure if that is sufficient because the fetch is not working.
That being said, Typescript also is not blowing up so I wonder if that means the issue is not reproduceable and therefore something with my setup? Perhaps my tsconfig settings 馃
Figured it out! export * as is a newly supported by Typescript as of 3.8. I upgraded my TS dependency and that fixed the issue. Thanks for the help on this!
Thanks for sharing your findings, @mitchconquer! I tried to make your codesandbox project work, but for some reason it ignores start()'s attempt to register a worker (you've manually placed the mockServiceWorker.js file correctly). Calling navigator.serviceWorker.register() works, however.
In any way, you can see that there are no TypeScript issues when using msw in a React + TS sandbox. I believe that having the 3.8+ TypeScript version is a current pre-requisite, so it could handle the export * as syntax.
Since there are a bunch of tooling operating on TypeScript 3.7, I believe it's for the compatibility the msw package shouldn't be distributed with 3.8-specific features.
I've issued a replacement for that syntax in #117, which should use explicit exports, fixing this error even on version 3.7.
@tryfonkov, could you please update to [email protected] and let me know that you have no TypeScript errors related to msw? That version should be compatible with TypeScript 3.7.
Once updated, you may see an error message in your browser's console. That's because this release changes the contents of mockServiceWorker.js file, so you'd have to run npx msw init <PUBLIC_DIR> once more. I apologize for this inconvenience, but I haven't designed a better way to distribute updated to the worker file, considering it's an external pre-requisite.
@kettanaito, sorry for late reply.
Yes, TS 3.7 did not support export * as syntax. Therefore, updating to TS 3.8 solved my problem.
Explicit exports are supported in TS 3.7 as well.
Thank!
@tryfonkov, my pleasure! Feel free to reach out in the issues in case you have any other questions regarding the library. I'm always happy to help.