blitz-js / babel-plugin-superjson-next

Automatically transform your Next.js Pages to use SuperJSON
MIT License
125 stars 15 forks source link

Compilation error: unexpected token #1

Closed dwightwatson closed 3 years ago

dwightwatson commented 4 years ago

After adding this to a Blitz app, before even making any changes to the codebase, I get an instant compilation error

error - /Users/dwight/Sites/myapp/node_modules/babel-plugin-superjson-next/dist/tools.js 4:4
Module parse failed: Unexpected token (4:4)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| //# sourceMappingURL=tools.js.map
| ;
>     }
|   };
| }
Skn0tt commented 3 years ago

Well, that seems weird 😕 Could you provide a minimal reproduction case?

dwightwatson commented 3 years ago

https://github.com/dwightwatson/blitz-superjson

Here's a fresh Blitz app - I added the projects scaffold and then changed app/projects/pages/projects/[projectId].tsx to render statically, assuming the plugin would automatically pass through the project.

(So just install, blitz db migrate, create a project through the UI and then visit it).

Let me know if this replicates it for you or if I can provide anything else.

Skn0tt commented 3 years ago

Thanks for providing the repro! It seems like something happened to the dist files during publishing. I tried to publish a new version (v0.1.3), but same problem:

We expect dist/tools.js to be published like this:

"use strict";function e(e){return e&&"object"==typeof e&&"default"in e?e.default:e}Object.defineProperty(exports,"__esModule",{value:!0});var r=e(require("superjson")),t=e(require("react"));function n(){return(n=Object.assign||function(e){for(var r=1;r<arguments.length;r++){var t=arguments[r];for(var n in t)Object.prototype.hasOwnProperty.call(t,n)&&(e[n]=t[n])}return e}).apply(this,arguments)}exports.withSuperJSONPage=function(e){return function(n){var o=r.deserialize(n);return t.createElement(e,Object.assign({},o))}},exports.withSuperJSONProps=function(e){return function(){try{return Promise.resolve(e.apply(void 0,arguments)).then((function(e){return n({},e,{props:r.serialize(e.props)})}))}catch(e){return Promise.reject(e)}}};
//# sourceMappingURL=tools.js.map

But instead this is what reaches the registry:

import SuperJSON from 'superjson';
import React from 'react';

function _extends() {
  _extends = Object.assign || function (target) {
    for (var i = 1; i < arguments.length; i++) {
      var source = arguments[i];

      for (var key in source) {
        if (Object.prototype.hasOwnProperty.call(source, key)) {
          target[key] = source[key];
        }
      }
    }

    return target;
  };

  return _extends.apply(this, arguments);
}

function withSuperJSONProps(gssp) {
  return function withSuperJSON() {
    try {
      return Promise.resolve(gssp.apply(void 0, arguments)).then(function (result) {
        return _extends({}, result, {
          props: SuperJSON.serialize(result.props)
        });
      });
    } catch (e) {
      return Promise.reject(e);
    }
  };
}
function withSuperJSONPage(Page) {
  return function WithSuperJSON(serializedProps) {
    var props = SuperJSON.deserialize(serializedProps);
    return React.createElement(Page, Object.assign({}, props));
  };
}

export { withSuperJSONPage, withSuperJSONProps };
//# sourceMappingURL=tools.js.map
SON(serializedProps) {
    var props = SuperJSON.deserialize(serializedProps);
    return React.createElement(Page, Object.assign({}, props));
  };
}

exports.withSuperJSONPage = withSuperJSONPage;
exports.withSuperJSONProps = withSuperJSONProps;
//# sourceMappingURL=tools.js.map

It seems like it’s re-transpiled at a different target level. Similar, but somehow different things happen with other files.

Interestingly, when inspecting the package to be published using yarn pack, everything seems fine.

Maybe it‘s a bug in TSDX? 🧐

flybayer commented 3 years ago

Interesting! Btw @Skn0tt you can publish test versions to npm as some random version like 0.1.3-aenof4h with some other tag like danger instead of latest. That way you can test npm without affecting releases for anyone else.

flybayer commented 3 years ago

@Skn0tt any update on this? Would be great to get this fixed as soon as feasible

Skn0tt commented 3 years ago

Haven’t forgot about it, will publish a fix tonight.

Skn0tt commented 3 years ago

@dwightwatson can you try out v0.1.4?

dwightwatson commented 3 years ago

Yeah, this appears to be working now. Thanks so much!