Unexpected token '!' #2900

New Issue

paustint · 2023-03-15T14:50:09Z

paustint commented

2023-03-15 14:50:09 +00:00

I have a user that started reporting an issue , which looks like it is coming from (var i=0;i!=d.length;++i)

Does anyone have any idea on what might be causing this?
This is causing my entire application to be broken for this one user and it just started happening.

message : Uncaught SyntaxError: Unexpected token '!'

Chrome version: 110.0.0 - 42

filename : webpack:///../../node_modules/xlsx/dist/cpexcel.js
code : cptable[1250] = (function(){ var d = "\u0000\u0001\u0002\u0003\u0004\u0005\u0006\u0007\b\t\n\u000...
method : [anonymous]
colno : 468
lineno : 795

I have a user that started reporting an issue , which looks like it is coming from `(var i=0;i!=d.length;++i)` Does anyone have any idea on what might be causing this? This is causing my entire application to be broken for this one user and it just started happening. ------ message : Uncaught SyntaxError: Unexpected token '!' Chrome version: 110.0.0 - 42 ``` filename : webpack:///../../node_modules/xlsx/dist/cpexcel.js code : cptable[1250] = (function(){ var d = "\u0000\u0001\u0002\u0003\u0004\u0005\u0006\u0007\b\t\n\u000... method : [anonymous] colno : 468 lineno : 795 ```

sheetjs commented

2023-03-15 16:57:48 +00:00

Are you overriding the xlsx resolution in your Webpack config? How are you importing the code? Are you using the latest version? (https://docs.sheetjs.com/docs/getting-started/installation/frameworks)

If you have access to the file, please test the following:

"""
The react-data-grid demo uses create-react-app (which uses Webpack under the hood): https://docs.sheetjs.com/docs/demos/grid/#rdg-demo

npx -y create-react-app sheetjs-cra --template typescript
cd sheetjs-cra
npm i -S https://cdn.sheetjs.com/xlsx-latest/xlsx-latest.tgz react-data-grid
curl -L -o src/App.tsx https://docs.sheetjs.com/rdg/App.tsx
npm run build
npx -y http-server build

Open a web browser to the displayed address and ensure that there are no errors in the console.
"""

Are you overriding the xlsx resolution in your Webpack config? How are you importing the code? Are you using the latest version? (https://docs.sheetjs.com/docs/getting-started/installation/frameworks) If you have access to the file, please test the following: """ The `react-data-grid` demo uses `create-react-app` (which uses Webpack under the hood): https://docs.sheetjs.com/docs/demos/grid/#rdg-demo ```bash npx -y create-react-app sheetjs-cra --template typescript cd sheetjs-cra npm i -S https://cdn.sheetjs.com/xlsx-latest/xlsx-latest.tgz react-data-grid curl -L -o src/App.tsx https://docs.sheetjs.com/rdg/App.tsx npm run build npx -y http-server build ``` Open a web browser to the displayed address and ensure that there are no errors in the console. """

paustint commented

2023-03-15 17:47:07 +00:00

Are you overriding the xlsx resolution in your Webpack config?

No

How are you importing the code?

import * as XLSX from 'xlsx';
68c9be94cf/libs/shared/ui-utils/src/lib/shared-ui-utils.ts (L57)

Are you using the latest version?

No, not yet - I am on an older version.

The user is on a pretty locked down corporate machine, so I am wondering if there is anything weird with chrome extensions or something. They are unable to try a different browser since that is not allowed by employer.

Here is the file where the exception is thrown: https://getjetstream.app/930.678963cc502eb432.js

I am planning on upgrading to the latest version and was also considering trying to lazy import the encoding stuff, since that is where the error is, in the hopes that the load would fail and for this one user I could just not load the encoding which I think should work.

Also - I was not 100% clear if I need the encoding or not? My users are global and will definitely have japanese and chinese characters in data that may be incldued in spreadsheets - but when I tested locally on my machine without loading the encoding tables it worked fine on my mac with Sheets and Google Drive. (I know windows may behave differently.)

Is the encoding only required for older versions of excel? (which it is very possible I have users that are using old versions - but have no way to know).

related issue: https://github.com/jetstreamapp/jetstream/issues/211

> Are you overriding the xlsx resolution in your Webpack config? No > How are you importing the code? `import * as XLSX from 'xlsx';` https://github.com/jetstreamapp/jetstream/blob/68c9be94cffcb599510b72d11533b299e798be07/libs/shared/ui-utils/src/lib/shared-ui-utils.ts#L57 > Are you using the latest version? No, not yet - I am on an older version. The user is on a pretty locked down corporate machine, so I am wondering if there is anything weird with chrome extensions or something. They are unable to try a different browser since that is not allowed by employer. Here is the file where the exception is thrown: https://getjetstream.app/930.678963cc502eb432.js I am planning on upgrading to the latest version and was also considering trying to lazy import the encoding stuff, since that is where the error is, in the hopes that the load would fail and for this one user I could just not load the encoding which I think should work. Also - I was not 100% clear if I need the encoding or not? My users are global and will definitely have japanese and chinese characters in data that may be incldued in spreadsheets - but when I tested locally on my machine without loading the encoding tables it worked fine on my mac with Sheets and Google Drive. (I know windows may behave differently.) Is the encoding only required for older versions of excel? (which it is very possible I have users that are using old versions - but have no way to know). related issue: https://github.com/jetstreamapp/jetstream/issues/211

sheetjs commented

2023-03-15 18:13:29 +00:00

Did you copy-paste the source from the console or is that the actual file?

Some of the UTF8 and latin-1 entities appear to have been translated to JS encoded versions. For example, \x83 appears in the codepage source as the entity but the linked source file has the equivalent of \\x83:

curl -L https://getjetstream.app/930.678963cc502eb432.js | grep x83 | wc -l
# prints 1
curl -L https://cdn.sheetjs.com/xlsx-0.19.2/package/dist/cpexcel.js | grep x83 | wc -l
# prints 0

Is there some step in the environment that is sanitizing strings or incorrectly converting to UTF8?

.

Broadly speaking, if you update to the latest version, the new ESM builds do not load codepage by default. Those have to be manually injected https://docs.sheetjs.com/docs/getting-started/installation/frameworks#encoding-support

.

The encodings are required for older XLS files as well as DBF, SYLK and a number of classic file formats. CSV and other plaintext formats will also use them to be consistent with Excel, but newer versions of Excel emit files with the UTF8 BOM.

Did you copy-paste the source from the console or is that the actual file? Some of the UTF8 and latin-1 entities appear to have been translated to JS encoded versions. For example, `\x83` appears in the codepage source as the entity but the linked source file has the equivalent of `\\x83`: ```bash curl -L https://getjetstream.app/930.678963cc502eb432.js | grep x83 | wc -l # prints 1 curl -L https://cdn.sheetjs.com/xlsx-0.19.2/package/dist/cpexcel.js | grep x83 | wc -l # prints 0 ``` Is there some step in the environment that is sanitizing strings or incorrectly converting to UTF8? . Broadly speaking, if you update to the latest version, the new ESM builds do not load codepage by default. Those have to be manually injected https://docs.sheetjs.com/docs/getting-started/installation/frameworks#encoding-support . The encodings are required for older XLS files as well as DBF, SYLK and a number of classic file formats. CSV and other plaintext formats will also use them to be consistent with Excel, but newer versions of Excel emit files with the UTF8 BOM.

paustint commented

2023-03-16 01:01:30 +00:00

The file here https://getjetstream.app/930.678963cc502eb432.js is the actual source code that is output of webpack bundling/minification.

There is nothing that I am explicitly doing here, just whatever webpack and plugins are doing. It has worked for multiple years and works for all other users - so really not sure why this is suddenly an issue out of nowhere.

I will give the new version a try and see if that resolves the issue.

The file here `https://getjetstream.app/930.678963cc502eb432.js` is the actual source code that is output of webpack bundling/minification. There is nothing that I am explicitly doing here, just whatever webpack and plugins are doing. It has worked for multiple years and works for all other users - so really not sure why this is suddenly an issue out of nowhere. I will give the new version a try and see if that resolves the issue.

paustint commented

2023-03-16 01:18:16 +00:00

Is it normal that the downloaded code via yarn into node_modules would look different than the code downloaded directly from the cdn?

Is it normal that the downloaded code via yarn into node_modules would look different than the code downloaded directly from the cdn? ![image](/attachments/d50e59b3-ffd7-4594-9b34-4eb21c0ee62a)

image.png

1.3 MiB

sheetjs commented

2023-03-16 02:28:59 +00:00

Quick primer: under the hood, it's all bytes. The character interpretation is driven by the encoding.

To see the correct bytes, download the raw file and view it. To download the file, you can run curl -LO https://cdn.sheetjs.com/xlsx-0.19.2/package/dist/cpexcel.js and then open that file in VSCodium.

The encoding is shown in the bottom bar (between the Spaces/Tabs indicator and the line ending indicator). The left side will probably say UTF-8. Click it, select "Reopen with Encoding" and choose "ISO 8859-1" to see something like the right side. To change it back, click "ISO 8859-1" then select "Reopen with Encoding" and choose "UTF-8"

.

There are a few possible issues (including known bugs with Next and the SWC minifier https://github.com/vercel/next.js/discussions/30237#discussioncomment-3839045 ) but it would help to build a local copy and share the JS source file. You can attach it here or email it to hello@sheetjs.com (do not copy and paste the source). It is possible that your host is corrupting the source.

Quick primer: under the hood, it's all bytes. The character interpretation is driven by the encoding. To see the correct bytes, download the raw file and view it. To download the file, you can run `curl -LO https://cdn.sheetjs.com/xlsx-0.19.2/package/dist/cpexcel.js` and then open that file in VSCodium. The encoding is shown in the bottom bar (between the Spaces/Tabs indicator and the line ending indicator). The left side will probably say UTF-8. Click it, select "Reopen with Encoding" and choose "ISO 8859-1" to see something like the right side. To change it back, click "ISO 8859-1" then select "Reopen with Encoding" and choose "UTF-8" . There are a few possible issues (including known bugs with Next and the SWC minifier https://github.com/vercel/next.js/discussions/30237#discussioncomment-3839045 ) but it would help to build a local copy and share the JS source file. You can attach it here or email it to hello@sheetjs.com (**do not copy and paste the source**). It is possible that your host is corrupting the source.

paustint commented

2023-03-16 03:53:13 +00:00

I have attached the source for this.

The 903.x file includes a bunch of other code that happened to be minified in the same bundle determined from webpack.

The 7273.x file is the new one where I am lazy importing cpexcel with the hope that if this were to fail it may not be catastrophic and crash the entire application if there is somehow a syntax error in the code.

export function initXlsx() {
  import('xlsx/dist/cpexcel.full.mjs')
    .then((module) => {
      XLSX.set_cptable(module);
    })
    .catch((ex) => {
      logger.error('Error loading xlsx', ex);
    });
}

I have attached the source for this. The 903.x file includes a bunch of other code that happened to be minified in the same bundle determined from webpack. The 7273.x file is the new one where I am lazy importing `cpexcel` with the hope that if this were to fail it may not be catastrophic and crash the entire application if there is somehow a syntax error in the code. ```typescript export function initXlsx() { import('xlsx/dist/cpexcel.full.mjs') .then((module) => { XLSX.set_cptable(module); }) .catch((ex) => { logger.error('Error loading xlsx', ex); }); } ```

930.678963cc502eb432.js.txt

1.3 MiB

7273.310ab9cc29869755.js.txt

794 KiB

Sign in to join this conversation.