CompilerOptions in tsconfig.json about s

[adamhaile]

Hi @ismail-codar --
Hmm, that sounds like a bundling / packaging issue. I haven't used NativeScript. Do you know how it handles bundling modules? Or how you're bundling the app?

The way the S package is set up, there's a "module" parameter in package.json that points to an es6-module version of the lib. This should be picked up by any bundler that can handle es6 modules (webpack 2, typescript 2, rollup).

The package's "main" property points to a UMD version of the library that should work with CommonJS, RequireJS and in the browser.

It sounds like you're using es6 module syntax, but that your bundler is picking up the UMD version of the library. Your bundler is then assuming that the default export from the library is accessed via a "default" property on the export object. That's how some es6->CommonJS bundlers are working, but not all. I'm using rollup to do the CommonJS bundling, and it generates CommonJS libs where the default export is the main export object.

In other words, your bundler is converting ...

import S from 's-js';

... to ...

var S = require('s-js').default;

... when it should be doing ...

var S = require('s-js');

Can you tell me more about your tsconfig.json and bunder settings, and maybe we can figure out what's going wrong?
-- Adam

[ismail-codar]

Here is some experiments on nativescript platform with visual studio code:

This is working but intellisense not working.

var S = require('s-js');

And this not working in runtime (S = undefined) but intellisense is working.

import S from 's-js';

If module changed es2015 to commonjs all of working with import S from 's-js' The choice is yours. But using only commonjs is enough according to me. I do not know if there is any other reason/advantage to use module=es2015.

[adamhaile]

@ismail-codar es2015 modules are important for any current system that understands them (webpack 2, typescript 2, rollup), and for all future ones.

If I'm right about what's going on, the core issue is that something in your build system is getting crossed up about which version (UMD or es2015) of the S lib it should use. Changing the tsconfig.json setting "fixes" it for you by putting the right lib in the wrong location. But it will break any build system that is looking in the right place.

I haven't seen this repro in the build environments I'm using. Would it be possible to post up a repro somewhere? Or perhaps give some details about the build system you're using and the config files? Is this a TS-only build, or webpack, or rollup or somesuch? I'd like to help, but I'm not sure where things are going awry.

[ismail-codar]

Hi @adamhaile I will publish my nativescript - s-js entegration work in a few days. It seems to be working fine right now. Working on the a sample will be good for find a solution.

Note: Setting up android sdk required. An easy starting point is http://docs.nativescript.org/start/ns-setup-installer and http://docs.nativescript.org/tutorial/chapter-1

[ismail-codar]

Sorry @adamhaile It's been a long time. Because priority work, holiday etc.. I just send surplus-nativescript and configured example project Can you try it?

Native mobile application development with s.js and surplus is good feature and POC application seems to be working successfully. Are you planning some marketting for s-js. For example: A website, logo, blogging, medium posts.. Potentially it can be popular over the react, vue, angular and others.

[adamhaile]

Thanks for the example, Ismail. I pulled and, yeah, I could repro the issue you're seeing.

The s-js package contains both es6 and commonjs modules, and what's going on is that typescript is compiling against the es6 modules, but nativescript is loading the commonjs one at runtime. The commonjs module was assembled by rollup, and it uses a different convention than typescript for modules containing a single default export. Specifically, typescript expects the default export to be at require('s-js').default while rollup puts it at just require('s-js'). When typescript loads require(s-js').default it gets undefined, as you saw.

There's no spec or dominant convention right now for how es6 modules should be compiled to commonjs ones, so I can see this issue coming up for other people. I'm going to experiment with adding a hidden, nonenumerable property to S, S.default === S. That should provide compatibility for build scenarios like yours. I just want to verify that it doesn't slow down the other calls -- I've seen cases where adding a property via defineProperty() appeared to slow down all property accesses to an object.

If I follow, your approach in surplus-nativescript is to create proxies for the DOM API calls that surplus uses. That's cool :). There's another fellow doing some experiments with using a DOM-in-js implementation to do server-side rendering with surplus. If you wanted to remove the cost of proxying the calls, you could fork the surplus compiler and rewrite compile.ts to generate code appropriate to Nativescript.

I am planning to do some improvements to surplus' docs and websites, for sure. I want to boost JSX compatibility first. As you noticed (spreads, dotted subcomponent names, etc), surplus initially only supported a subset of JSX. I'm working now to fill that out while (hopefully) preserving performance. I want to get that done before too many people come knocking.

[adamhaile]

Just pushed a version 0.4.4 that should add compatibility for more commonjs build scenarios. Please confirm that it fixes your issue.

[ismail-codar]

Thanks for the fix defineProperty good solution. I will try it now..

The performance of the surplus-preprocessor is not very important but generated code performance is important. It is necessary not to mix.

I think the other approach is actually for surplus-nativescript (rewrite compile.ts and code generating for nativescript platform). But it would be difficult for me. Is the surplus preprocessor section some codes generated by ANTLR like compiler generator or handwritten? Something hard in both cases. Creating proxies is practical solution. for me

I think another approach would be more accurate. Thats typescript is allready best full featured JSX or TSX parser. It contains parser, AST and visitor. Instead of writing your own compiler! typescript compiler API and custom transform features can be solution.

You can check https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API and http://blog.scottlogic.com/2017/05/02/typescript-compiler-api-revisited.html But surplus preprocessor is near the completion.

[ismail-codar]

I made the necessary experiment. You can close this issue at any time.

[adamhaile]

Great, glad to hear it's working for you!