I am using msw/node with my react-testing-library integration test.
When we mock fetch api with msw/node, we have to use polyfills for that since node does not support browser specific api such as localstorage, fetch.
msw documentation also states that we have to use polyfills for unsupported features.
It seems that we can use whatwg-fetch for mocking fetch api in msw/node environment as others suggest.
But whatwg-fetch states that we cannot use them in node environment, and this is why I am confused.
Is this collision happening because msw/node's environment is not a native node environment? It seems that both jest and msw/node runs on node environment, and what makes msw/node environment enable to use whatwg-fetch available?
Thank you.
Related
I have a Next.js 13 app that was deployed to the Edge on Cloudflare Pages with experimental: { runtime: 'experimental-edge' }, but requirements were updated and I need to include our feature flag dependency LaunchDarkly - and retrieve the feature flags via getServerSideProps.
Inside getServerSideProps I tried launchdarkly-node-server-sdk, launchdarkly-node-client-sdk, and launchdarkly-js-client-sdk, but they either require a Node specific library (fs and others) or window.
launchdarkly-cloudflare-edge-sdk with #cloudflare/kv-asset-handler looks promising, so I followed the template, but I'm not sure how to extend a Next.js app to have this functionality. For example, do I put the worker into a middleware.ts function or somehow extend the vercel build step to include this functionality.
I haven't tested this out but I am guessing you may need to use the Cloudflare SDK throughout since Cloudflare would deploy the functions as Cloudflare Workers, which is a non-Node runtime.
In a typical Next.js deployment, you'd use the Node server SDK for any server side code (like getServerSideProps) but my assumption is that this may cause errors due to the fact that it relies upon some Node-specific APIs that I am not sure the Workers runtime supports. We (LaunchDarkly) are working on updates to our JavaScript SDKs to better support non-Node runtimes but I don't have an ETA on their release.
By default, a NextJs middleware is run using the Edge runtime and from what I understand this is because the middleware is meant to be run on the edge network instead of the main server (being run on the edge network reduces the latency so this offers improved performance in some scenarios).
The downside of this is that the Edge runtime comes with some restrictions in terms of what it can run (list here).
My question is: is there any way to make a middleware run using the default runtime instead of the Edge runtime?
In my situation, we're not hosting anything on the edge so the Edge runtime imposes some restrictions on us without providing any benefits. A possible workaround would be to use a custom middleware instead of a NextJs one, but unless this is the only choice, I would rather use the NextJs middleware architecture & plumbing instead of building our own.
P.s.: We're using NextJs 12.1.6 (latest version at the moment of writing this question)
There's no way to do it at the moment, but it's being worked on. See RFC: Switchable Next.js Runtime
At the moment if you need node apis in your middleware you can work around the issue by making api routes that do stuff with node apis and then calling them from your middleware. You should definitely try that one out instead of making custom middleware with custom server I assume, since custom servers have limitations.
Next.js 13 added option to change the runtime, but I don't think the setting applies to middleware. The setting can be used to make everything run on the edge though. https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes#global-runtime-option
Now it's possible to determine at global and segment levels which runtime should be used with Next.js 13.
This configuration is for defining the runtime for global:
module.exports = {
experimental: {
runtime: 'experimental-edge', // 'node.js' (default) | experimental-edge
},
};
https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes#global-runtime-option
If you want to determine at the segment (aka server component) level, the only thing to do is export a runtime constant variable.
[app/layout.js]
export const runtime = 'experimental-edge'; // 'node.js' (default) | 'experimental-edge'
https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes#segment-runtime-option
I want to start using the framework Spring Cloud Contract for contract testing. But does Spring Cloud Contract support JavaScript and JMS?
I haven't found any information about this.
As for the JMS, we do support it either via spring-integration or Apache Camel. You can also write your own JMS support. It's enough to register a couple of beans.
As for Javascript and non-jvm languages. There's no out of the box support but we have a process for that. The workflow is described here (in those cases the consumer is a Java app but in the next section I'll describe how the flow would differ) - https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_common_repo_with_contracts or https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_step_by_step_guide_to_cdc. We will try to obviously simplify the process but currently there's a bunch of manual tasks to be done (not very tedious though).
The consumer can very easily download and run the stubs. Just clone https://github.com/spring-cloud-samples/stub-runner-boot, build it and push the fat jar to your Nexus/Artifactory. This application will be used by the consumers to automatically download stubs and run them locally. As a consumer you can then call java -jar stub-runner-boot --stubrunner.ids="com.example.groupid:artifactid:classifier:version:8090" --stubrunner.repositoryRoot="http://localhost:8081/artifactory/libs-release-local" . That way the application will start, download the provided jar with stubs from the given address where your artifactory is. Now your front end application can call the stubs of the producer at localhost:8090.
Of course we will try to simplify the cloning and pushing process (https://github.com/spring-cloud/spring-cloud-contract/issues/37) etc. but for now you have to do those 2 steps manually.
UPDATE:
With this article https://spring.io/blog/2018/02/13/spring-cloud-contract-in-a-polyglot-world we're presenting a way how to work in a polyglot environment. It's enough to use the provided docker images to run contract tests against a running application and to run the stub runners too.
I am just starting with Meteor and working on an existing project. I am running into an issue with one of the packages(observatory-apollo) that's has the following line:
__meteor_bootstrap__.app.use Observatory.logger #TLog.useragent
It is complaining that __meteor_bootstrap__.app is undefined.
What is __meteor_boostrap__ exactly? I can't seem to find a description of what it is but from threads, people seem to know how to use it. I can only see it defined in boot.js, but it doesn't really tell me much...
Meteor uses connect npm module under the hood for various reasons, to serve static files, for example. __meteor_bootstrap__.app was the reference to connect app instance.
Before it was __meteor_bootstrap__.app but it changed couple of releases ago and became WebApp.connectHandlers object and is part of WebApp package.
WebApp is a standard package of Meteor, core package for building webapps. You don't usually need to add explicitly as it is a dependency of standard-app-packages.
Example of usage the connectHandlers is to inject connect middlewares in the same way as you would use any connect middleware (or some express middlewares, express is built on top of connect):
WebApp.connectHandlers
.use(connect.query())
.use(this._config.requestParser(bodyParser))
You can look at meteor-router Atmosphere package and take it as an example: https://github.com/tmeasday/meteor-router/blob/master/lib/router_server.js
More about connect: https://npmjs.org/package/connect
I am using SimpleTest API and PHPUnit Test API. Does any of them support automated bug logging support . And if not then how can I will provide this feature ?
PHPUnit can, for example, interact with issues in
Trac ( https://github.com/sebastianbergmann/phpunit-ticketlistener-trac )
GitHub ( https://github.com/sebastianbergmann/phpunit-ticketlistener-github )
and a couple others: http://pear.phpunit.de/
Buiding one that fits your propose sure is possible.
Also there are other ways to make PHPUnit tell you what is happening like
Test listeners. Where you can really act on everything PHPUnit does.
The xml or json output. That you can parse and act on it accordingly