Error "LB: Transpiled file would overwrite source file. Aborted!" - atom-editor

I've been given a coding task as part of a job interview it's a little outside my ken but I'm trying it anyway. They've given me their boilerplate and asked me to make certain changes. It is a React app built with webpack.
When I try to edit a file [addendum: I should have said "edit and save"], I get the Error "LB: Transpiled file would overwrite source file. Aborted!"
I assume the "LB" refers to language-babel. I can get it to work by disabling language-babel. Maybe I'm confused, but aren't source files exactly what I want to edit? I've never had this problem on any other project on which I've worked.
I've searched and can't find much on this error. I'm on Windows 10 with Atom 1.19.7 X64 and language-babel 2.75.2.
The .babelrc that came with the boilerplate is:
```
{
"presets": ["react", "es2015"],
"plugins": [
["import", [{
"libraryName": "antd",
"style": "css"
}, {
"libraryName": "lodash",
"libraryDirectory": "",
"camel2DashComponentName": false,
}, {
"libraryName": "components",
"libraryDirectory": "",
"camel2DashComponentName": false,
}, {
"libraryName": "HOCS",
"libraryDirectory": "",
"camel2DashComponentName": false,
}]],
"transform-runtime",
"transform-class-properties",
"transform-object-rest-spread",
"dynamic-import-node",
]
}
```
Thank you in advance for your help.

Related

Debug Next.js App with VSCode in NX monorepo

I'm currently trying to debug a Next.js Application inside a NX monorepo.
I have enabled the Auto Attach setting in VSCode's User Settings.
When I start the Application using the serve command, I can see output in the Debug Console and also print out the current process by typing process or console.log(process) into the Debug Console.
However, I cannot set any breakpoints in the server side code, for example in getServerSideProps.
I checked Next.js Debugging Documentation for the missing pieces, and tried setting the NODE_OPTIONS='--inspect' in my Next.js Application via .env file.
Update: Seems like it's a missing feature on NX.
Got it working, thanks to the information from this Pull Request.
.vscode/launch.json
{
"version": "0.2.0",
"resolveSourceMapLocations": ["${workspaceFolder}/**", "!**/node_modules/**"],
"configurations": [
{
"name": "name-of-the-app – Server",
"type": "node",
"request": "launch",
"runtimeExecutable": "yarn",
"runtimeArgs": [
"nx",
"run",
"name-of-the-app:serve",
"-r",
"ts-node/register",
"-r",
"tsconfig-paths/register"
],
"outputCapture": "std",
"internalConsoleOptions": "openOnSessionStart",
"console": "internalConsole",
"env": {
"TS_NODE_IGNORE": "false",
"TS_NODE_PROJECT": "${workspaceFolder}/apps/name-of-the-app/tsconfig.json"
},
"cwd": "${workspaceFolder}/apps/name-of-the-app/"
}
]
}
Note: I'm using yarn. You might have to replace it with npm instead.

Behavior change in speech-rule-engine 3.2?

I'm using the speech-rule-engine to generate English text from MathML. When trying to upgrade from v3.1.1 to v3.2.0 I'm seeing tests fail for reasons I don't understand.
I created a simple two file project that illustrates the issue:
package.json
{
"name": "failure-example",
"license": "UNLICENSED",
"private": true,
"engines": {
"node": "14.15.5",
"npm": "6.14.11"
},
"scripts": {
"test": "jest"
},
"dependencies": {
"speech-rule-engine": "3.2.0"
},
"devDependencies": {
"jest": "^26.6.3"
},
"jest": {
"notify": false,
"silent": true,
"verbose": true
}
}
example.test.js
const sre = require('speech-rule-engine');
beforeAll(() => {
sre.setupEngine({
domain: 'mathspeak'
});
});
test('simple single math', () => {
expect(JSON.parse(JSON.stringify(sre.engineSetup(), ['domain', 'locale', 'speech', 'style'])))
.toEqual({
locale: 'en',
speech: 'none',
style: 'default',
domain: 'mathspeak',
});
expect(sre.engineReady())
.toBeTruthy();
expect(sre.toSpeech('<math><mrow><msup><mn>3</mn><mn>7</mn></msup></mrow></math>'))
.toBe('3 Superscript 7');
});
Running npm install and npm run test results in a failure because SRE is returning 37 instead of 3 Superscript 7. Editing package.json to use v3.1.1 of the engine and rerunning results in a passing test.
Obviously something has changed, but I'm totally missing what I need to do to adapt. Has anyone else encountered this, or see what I clearly do not?
Problem solved, with the help of the maintainer of SRE. The problem is not in 3.2.0, but that jest does not wait for sre to be ready. The test was only correct by a fluke in 3.1.1 as the rules were compiled into the core. The following test fails with the above setup in 3.1.1 as well as the locale is not loaded:
expect(sre.toSpeech('<math><mo>=</mo></math>'))
.toBe('equals');
Expected: "equals"
Received: "="
The main reason is that jest fails to load the locale file. Setting "silent": false will show the error:
Unable to load file: /tmp/tests/node_modules/speech-rule-engine/lib/mathmaps/en.js
TypeError: Cannot read property 'readFileSync' of null
The reason for this error is that jest does not know that it runs in node. Adding:
"testEnvironment": "node",
to the jest configuration in package.json causes the expected behavior.

Did Firebase Cloud Functions ESLint change recently?

I created a cloud function project with firebase a few months ago, and used linting.
I recently created a new cloud function project with linting, and now the linter is complaining about random rules I never set. I don't remember it enforcing nearly the amount of style rules a few months ago.
Things like:
This line has a length of 95. Maximum allowed is 80
Missing JSDoc comment
Missing Trailing comma
expected indentation of 2 spaces but found 4
Strings must use singlequote
It's also not letting me use async/await.
I found out I can individually set these rules in my .eslintrc.js file, but that's annoying and I don't want to do that. By default, why aren't these rules disabled? I just want basic rules that make sure my code won't fail when run, not random style preferences like single/double quotes and max line length.
Is there any way to use just basic linting functionality with firebase functions?
I ran into the same issue as you. The new, more strict linting rules seem to come from the fact that Firebase functions use the "google" eslint base configuration plugin by default now. Read more about configuring ESLint plugins in the docs. My older Firebase functions were using tslint without issue.
Here's what my .eslintrc.js file looked like while I was getting style errors from eslint:
module.exports = {
env: {
es6: true,
node: true,
},
extends: [
'eslint:recommended',
'plugin:import/errors',
'plugin:import/warnings',
'plugin:import/typescript',
'google',
],
parser: '#typescript-eslint/parser',
parserOptions: {
project: ['tsconfig.json', 'tsconfig.dev.json'],
sourceType: 'module',
},
ignorePatterns: [
'/lib/**/*', // Ignore built files.
],
plugins: ['#typescript-eslint', 'import'],
rules: {
quotes: ['error', 'double'],
},
};
I deleted 'google' from the extends property, which seemed to resolve almost all of the style linting issues.
Now it looks like this:
module.exports = {
env: {
es6: true,
node: true,
},
extends: [
'eslint:recommended',
'plugin:import/errors',
'plugin:import/warnings',
'plugin:import/typescript',
],
parser: '#typescript-eslint/parser',
parserOptions: {
project: ['tsconfig.json', 'tsconfig.dev.json'],
sourceType: 'module',
},
ignorePatterns: [
'/lib/**/*', // Ignore built files.
],
plugins: ['#typescript-eslint', 'import'],
rules: {
quotes: ['error', 'double'],
},
};
You can get rid of the google extends value but I would suggest keeping it and just turning off the rules that bother you the most, which for me is indentation and max length (of lines):
module.exports = {
root: true,
env: {
es6: true,
node: true,
},
extends: [
"eslint:recommended",
"google",
],
rules: {
"quotes": ["error", "double"],
"indent": ["off"],
"max-len": ["off"],
},
};
For anyone who is confused by this, there is a lint config file in the Cloud Functions folder that you can edit. As of this answer, that file is named .eslintrc.js.

Jupyter Notebook validation failed

When I open a file in jupyter notebook, I get this error.
Notebook validation failed: {'model_id': '47c3f67b01814c2baeeca6efa0a79e2d', 'version_major': 2, 'version_minor': 0} is not valid under any of the given schemas:
{
"model_id": "47c3f67b01814c2baeeca6efa0a79e2d",
"version_major": 2,
"version_minor": 0
}
I had the same problem and this solution works like a charm:
https://github.com/jupyter/nbformat/issues/161
TLDR: open your file on a text editor and replace "nbformat_minor": 1 with "nbformat_minor": 4
Check if you activated conda environment correctly. In my case conda environment was not correctly activated so that was the problem. As I activated correctly everything worked normal.
I think different issues cause the error, one of them is:
The bug happens because the code blocks from Colab are missing "outputs':[] and "execution_count":null.
{
"cell_type": "code",
"metadata": {
"id": "e2769b9e0005"
},
"source": [
"!pip install git+https://github.com/google/starthinker\n"
]
},
To fix add the missing fields to the colab source for any code block only not markdown:
{
"cell_type": "code",
"execution_count": null,
"outputs": [],
"metadata": {
"id": "e2769b9e0005"
},
"source": [
"!pip install git+https://github.com/google/starthinker\n"
]
},

“You may need an appropriate loader to handle this file type” with Webpack and CSS

I an new to webpack, and I have been able to get it to packup my javascript, but the CSS eludes me. I keep getting a:
“You may need an appropriate loader to handle this file type”
One the first line of my css file. The CSS file is simple:
body {
color:red
}
The webpack.config.js looks like this:
module.exports = {
debug: true,
entry: [ './sdocs.js' ],
output: {
filename: './[name].bundle.js'
},
loaders: [
{ test: /\.css$/, loader: "style-loader!css-loader" },
],
}
sdocs.js is also simple and looks like this:
require('./sdocs.css');
Finally the result of running webpack look like this:
ERROR in ./sdocs.css
Module parse failed: C:\Users\Tim\PhpstormProjects\xxx\sdocs.css
Unexpected token (1:5)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (1:5)
at Parser.pp.raise (C:\Users\Tim\PhpstormProjects\xxx\node_modules\acorn\dist\acorn.js:923:13)
at Parser.pp.unexpected (C:\Users\Tim\PhpstormProjects\xxx\node_modules\acorn\dist\acorn.js:1490:8)
at Parser.pp.semicolon (C:\Users\Tim\PhpstormProjects\xxx\node_modules\acorn\dist\acorn.js:1469:73)
at Parser.pp.parseExpressionStatement (C:\Users\Tim\PhpstormProjects\xxx\node_modules\acorn\dist\acorn.js:1994:8)
at Parser.pp.parseStatement (C:\Users\Tim\PhpstormProjects\xxx\node_modules\acorn\dist\acorn.js:1772:188)
at Parser.pp.parseTopLevel (C:\Users\Tim\PhpstormProjects\xxx\node_modules\acorn\dist\acorn.js:1666:21)
at Parser.parse (C:\Users\Tim\PhpstormProjects\xxx\node_modules\acorn\dist\acorn.js:1632:17)
at Object.parse (C:\Users\Tim\PhpstormProjects\xxx\node_modules\acorn\dist\acorn.js:885:44)
at Parser.parse (C:\Users\Tim\PhpstormProjects\xxx\node_modules\webpack\lib\Parser.js:902:15)
at DependenciesBlock.<anonymous> (C:\Users\Tim\PhpstormProjects\xxx\node_modules\webpack\lib\NormalModule.js:104:16)
at DependenciesBlock.onModuleBuild (C:\Users\Tim\PhpstormProjects\xxx\node_modules\webpack-core\lib\NormalModuleMixin.js:310:10)
at nextLoader (C:\Users\Tim\PhpstormProjects\xxx\node_modules\webpack-core\lib\NormalModuleMixin.js:275:25)
at C:\Users\Tim\PhpstormProjects\xxx\node_modules\webpack-core\lib\NormalModuleMixin.js:259:5
at Storage.finished (C:\Users\Tim\PhpstormProjects\xxx\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:38:16)
at C:\Users\Tim\PhpstormProjects\xxx\node_modules\graceful-fs\graceful-fs.js:78:16
at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:439:3) # ./sdocs.js 1:0-22
I have triple checked, css-loader and style-loader are loaded at the local level. I had them installed globally at first, but i removed them globally and reinstalled them locally. BTW, the debug flag did nothing extra, no change in output, which i thought was weird.
I am running on a windows platform is that matters
Ok,
This is what fixed it for me if anyone runs across this. The issue was in the webpack.config.js. The one the finally worked looked like this:
module.exports = {
debug: true,
entry: [ './sdocs.js' ],
output: {
filename: './[name].bundle.js'
},
module: {
loaders: [
{ test: /\.css$/, loader: "style-loader!css-loader" },
],
}
}
The piece that was missing was moving the loaders key under a modules key.
I tried specifying 'loaders' in 'module' key. But, it didn't work for me. I think for webpack versions above 2.5.1, adding a rule in 'module' works perfectly.
Add this in your webpack.config.js
module: {
rules:[
{ test: /\.css$/, use: [ 'style-loader', 'css-loader' ] }
]
}
When you add it as a rule you wouldn't have to provide tha loaders key separately!
I was facing this problem for about 10 days. so here's the solution i found to fix this problem. After using create-react-app you created a react app, first run the script npm run eject.
Then, go to the following link https://webpack.js.org/loaders/, click on the val-loader and install it as described there, then install the url-loader file.
It has to work now.
I had met the same issue you meet. Maybe you were in dev environment (hot reload), just press ctrl+c to kill the process on terminal, and reopen dev env (npm run dev).

Resources