I have problems deploying my meteor app with meteor-now. I followed this tutorial here. I also tried deploying with ZEIT's OSX Client but it always throws the same error. Does anyone know a workaround?
Edit 1:
This is my package.json
{
"name": "helloworld",
"private": true,
"scripts": {
"start": "meteor run"
},
"dependencies": {
"babel-runtime": "^6.26.0",
"meteor-node-stubs": "^0.3.2"
}
}
With transition to now v. 2.0 there is basically no more option to use it with Meteor. See also the thread on meteor-now and 2.0:
jkrup commented on 9 Nov 2018
Unfortunately with the current planned direction of Now, you're correct that it indicates MeteorJS will become essentially incompatible with Now.
However, I won't let that be the end to this project. Which will remain the easiest/zero-config way to deploy meteor apps. I've actually have already experimented with deploys on a different platform that starts very cheap (
I'll also try to reach out to some people at Zeit and see if they can help come up with a solution as well. #timneutkens 😉
https://github.com/jkrup/meteor-now/issues/133
You can also read more in the migration guide: https://zeit.co/docs/v2/platform/upgrade-to-2-0/
Okay so I tried to switch my platform to now 1 but for my account this is already not working anymore. The option is on https://zeit.co/account already disabled:
If you are able to still use platform v.1 you may configure in your package.json a property "now": { ... } or add a now.json and configure your now service there.
If you configure using now.json you may place it in your project root and also run meteor-now ... --local-config.
Related
I am facing an error that caused by lower version of TypeScript, root cause is I update prettier version, related post: https://github.com/DefinitelyTyped/DefinitelyTyped/discussions/60310
So dependency issue was:
React -> TypeScript#4.7.4
Other-library -> Webpack-dev-server -> TypeScript#3.8.2
Prettier -> TypeScriptv4+
Since Prettier require TS version 4+ and the Webpack-dev-server has a version of 3.8.2, that will cause the program to throw error.
I can not change the version of Other-library, but I still need the version of TypeScript to be v4+
I am looking at this post:How do I override nested NPM dependency versions?
This seems does exactly what I needed to do.
But after I use the overrides property in package.json, I do see React is pickup the TypeScript version 4.7.4,
howerver I get the following error:
Child process failed to process the request: Error: Debug Failure. Palse expression. at resolveNamesWithLocalCache, at typescipt/lib
Thanks
My package json looks like:
{
"devDependencies": {
"typescript": "^4.7.4"
},
"overrides": {
"webpack-dev-server": {
"typescript": "$typescript"
}
}
}
`
So I checked, typescript is only "devDependencies" to webpack-dev-server. It's NOT supposed to be installed at all. How did you even end up in this situation 😂
It must be something about the way you install those packages. I don't know what happened, just try remove node_modules folder entirely, and also package-lock.json, then npm install again. You don't need that "overrides" field.
Additionally, it sounds to me this whole mayhem starts because of #types/prettier. HOWEVER, unless you have a very specific use case (which I seriously doubt) that requires integrating with prettier's programmatic API, through hand written TS code, you don't even need #types/prettier in the first place. Just get rid of that troublemaker. All #types/* packages are optional.
I can't get Next.js' Fast Refresh feature to work with a VS Code Remote Container. I can run npm run dev and see the app running on localhost on my machine, so the container works fine - only the Fast Refresh has no effect at all.
Next.js version: v11.0.1
I tried this both with Windows 10 and Ubuntu 20.04 (on WSL 2).
I already tried to use a custom webpack middleware in the next.config.js like so (see https://github.com/vercel/next.js/issues/2179#issuecomment-316568536):
module.exports = {
webpackDevMiddleware: (config) => {
// Solve compiling problem via vagrant
config.watchOptions = {
poll: 1000, // Check for changes every second
aggregateTimeout: 300, // delay before rebuilding
};
return config;
},
};
...which will trigger a recompile on code changes, but the browser does not update.
Also, the requests to "HMR" are failing:
How to reproduce:
Install the Remote Containers extension
Open any new folder
Open the command palette and type/select "Remote-Containers: Rebuild and Reopen in Container"
Type/select "Node.js"
Type/select version "16" and wait for the container to start
Go to the .devcontainer folder and open the devcontainer.json
Edit the config by adding "forwardPorts": [3002], to make the app available on your host and rebuild the container (via VS Code's command palette)
From the terminal, install Next.js, e.g.: npx create-next-app --use-npm --example with-typescript-eslint-jest my-app
Move all the files from my-app to your VS Code project root folder. This has to be done because create-next-app does not work installing in the project root folder via ., because there's already the .devcontainer folder.
Optional: Create a next.config.js and add the snippet for the Webpack dev middleware as seen above
Edit the package.json script to use a specific port: "dev": "next dev -p 3002", (or, if you use WSL 2: next dev -p 3002 -H ::)
From the terminal, start the app npm run dev
Open the browser on http://localhost:3002
The app is showing. Make changes in the code -> even a recompiled app will not show the changes in the browser. A reload of the page in the browser will show the changes though.
With Create React App, there's an advanced configuration without ejecting (called CHOKIDAR_USEPOLLING), which makes their Fast Refresh work with Remote Containers.
Earlier I created a feature request, but maybe someone already managed to make this work without huge changes in the configuration/setup?
A lot has changed between me noticing this issue and the current version of Next.js (v12.1.6).
I just tried it out again and it finally seems to work! 🥳
I'm going to change my Next.js projects to use devcontainers and maybe other stuff does not work, but at least for Fast Refresh, this topic is solved.
If you're following the steps above, the most basic setup should look like the following. It is based on the default "Node.js v16" devcontainer preconfiguration.
You don't even need to forwardPorts anymore!
// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.234.0/containers/javascript-node
{
"name": "My project",
"build": {
"dockerfile": "Dockerfile",
// Update 'VARIANT' to pick a Node version: 18, 16, 14.
// Append -bullseye or -buster to pin to an OS version.
// Use -bullseye variants on local arm64/Apple Silicon.
"args": { "VARIANT": "16" }
},
"settings": {},
"extensions": [
"dbaeumer.vscode-eslint"
],
// Use 'forwardPorts' to make a list of ports inside the container available locally.
// "forwardPorts": [],
// Use 'postCreateCommand' to run commands after the container is created.
// "postCreateCommand": "yarn install",
// Comment out to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
"remoteUser": "node"
}
Question: How can I fix a GitHub Security Vulnerability that results from a Library Dependency's Dependencies?
Context:
I received the following security vulnerability recently:
1 handlebars vulnerability found in package-lock.json 10 days ago
Adding one of these lines to the package.json file does not appear to resolve the security issue. Rather, the only instance I have found of handlebars being potentially < 4.3.0 is a reference in the package-lock.json:
"istanbul-reports": {
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/istanbul-reports/-/istanbul-reports-2.1.1.tgz",
"integrity": "sha512-FzNahnidyEPBCI0HcufJoSEoKykesRlFcSzQqjH9x0+LC8tnnE/p/90PBLu8iZTxr8yYZNyTtiAujUqyN+CIxw==",
"dev": true,
"requires": {
"handlebars": "^4.1.0"
}
},
When traversing the dependency chain in the package-lock.json file, "istanbul-reports" is pulled when using Jest. Unfortunately, below appears to be the most recent version.
"devDependencies": {
"jest": "^24.5.0"
}
Any suggestions on how I can remediate or fix this? Thank you!
You should be using {{double handlebars}} unless you explicitly want your input not to be escaped (which you want 99% of the time, as user input can never be trusted.)
Here are the docs - https://handlebarsjs.com/guide/#html-escaping
if e.g. you let your user input data and then display it on your page in {{{input}}} a user could use that to insert a malicious script
I am testing a React app, having essentially followed the standard, officially-blessed create-react-app setup.
I have written my test as follows:
import React from 'react';
import {shallow} from 'enzyme';
import MyComponent from './MyComponent';
describe('MyComponent', () => {
it('should have the expected properties', () => {
const wrapper = shallow(<MyComponent/>);
expect(wrapper.props()).toMatchObject({a: 1});
});
});
My package.json contains the following:
{
...
"devDependencies": {
"enzyme": "^2.6.0",
"react-scripts": "0.8.3",
...
},
"dependencies": {
"react": "^15.4.1",
...
},
"scripts": {
"test": "react-scripts test --env=jsdom",
...
},
"jest": {
"automock": false
}
}
When I run the tests I get the following error message: TypeError: expect(...).toMatchObject is not a function.
However, the react-scripts documentation states that Jest is one of the built-in tools used, e.g. I don't have to npm install it. And the Jest documentation clearly shows that toMatchObject is a function.
So why do I get this error message?
tl;dr: Run npm install jest to get the latest (v18+) jest.
Original answer in early Dec 2016:
I have discovered that this is an issue with Jest itself. It is documented here. If I read it correctly, it's not so much a bug as it is a feature-in-the-works that made its way into the documentation before it was actually ready for public release. Apparently, it should be coming out any day now. In the mean time, someone (the Jest team? someone else?) has provided a helper which can be found here to fill in for this matcher until its officially available. I haven't actually tried this helper, and I suspect it might disappear soon, but I thought I'd let any interested readers know about it if they really want this feature.
Update in early January 2017:
According to this website the toMatchObject matcher was included in Jest on approximately Jan 3, 2017. That was for Jest v18 (18.0.0? ... it's currently at 18.1.0). This was still not included in the basic React download, as this matcher still did not work for me when I deleted my node_modules folder and re-npm install-ed everything. However, if I specifically updated jest with npm install jest then node_modules/jest/package.json indicated that jest was now updated (for me on Jan 15, 2017, updated to version 18.1.0) and toMatchObject now seems to work.
...Actually, the solution in the above paragraph seems fickle, as it did work when I initially used it, but then stopped working again shortly after that (after again re-deleting node_modules, re-npm installing everything, re-doing npm install jest, and even trying #Scimonster's suggestion from the comments, i.e. deleting node_modules/react-scripts/node_modules/jest). I did find another working hack: manually adding the actual toMatchObject code from here to node_modules/react-scripts/node_modules/jest-matchers/build/matchers.js (after reverting some ES6/typescript/babel?-ish syntax). I presume this will all be fixed in a not-too-far-in-the-future update to React, but for now this works for me (at least for the moment!).
Already applied require('events') but still the warning is keep showing, what is that i am doing wrong here? Why process.EventEmitter is keep showing up even its not used?
Node v6.7.0 it works, but v6.9.1 this is happening on CentOS 7.2
var pro = require('events');
var port = parseInt(config.server.port, 10);
var io = require('socket.io').listen(port); // This line is causing it???
Output Warning:
dev environment detected
info - socket.io started
(node:32708) DeprecationWarning: process.EventEmitter is deprecated. Use require('events') instead.
EDIT:
I used $ npm install
where package.json had following:
{
"name": "TEST",
"description": "TEST",
"version": "0.0.2",
"dependencies": {
"getconfig": "0.3.0",
"node-uuid": "1.2.0",
"socket.io": "0.9.16",
"yetify": "0.0.1"
},
"main": "test.js",
"repository": {
"type": "git",
},
"devDependencies": {
"socket.io-client": "0.9.16",
"precommit-hook": "0.3.10",
"tape": "^2.13.1"
},
"scripts": {
"test": "node test.js"
}
}
You may be using and old version of socket.io because in your code you don't use process.EventEmitter directly. If this program that you posted shows the warning then this is what could be the problem.
On my system the same program doesn't cause the problem - node 7.0.0 and socket.io 1.5.1 - but maybe you didn't include all of your code in your example (e.g. the config.server.port is not defined so you seem to have removed some portions of your code that may be relevant here).
You can see the version that you're using in:
node_modules/socket.io/package.json
See your own package.json and search for a line like:
"socket.io": "^1.4.8"
(like this line in one of my projects on GitHub) to see what version is installed with npm install and update the version if it's outdated. It's also possible that you have the socket.io module installed globally.
You can use David to let you know that you have outdated dependencies.
You can use Greenkeeper to help you keep your dependencies up to date.
(It's also good to add Snyk to let you know about vulnerabilities in your dependencies.)
Update
You posted your package.json and indeed you use an old version of socket.io:
"socket.io": "0.9.16",
so this exact version is installed when you run npm install. The current version is 1.5.1 - see:
https://www.npmjs.com/package/socket.io
You can change the version and rerun npm install. If the code is exactly the same as posted then you shouldn't need to change your code. If there is more code then see http://socket.io/docs/migrating-from-0-9/ for things that may need to be changed.
If you use CI tests, David and Greenkeeper, as I suggest above, then all of that (updating the version, testing if it still works etc.) would basically be done for you automatically.
If you use Snyk, as I also suggest above, then you'll know the version of socket.io that you're using has high-severity vulnerabilities, including Denial of Service and Remote Memory Exposure - that you now have in your code. See:
https://snyk.io/test/npm/socket.io/0.9.15
https://snyk.io/test/npm/socket.io/1.5.1
So as you can see, updating the socket.io dependency is important for more serious reasons than just the deprecation warning.