ozanmakes / ppx-tea-jsx

Reason JSX syntax for BuckleScript-TEA
MIT License
51 stars 2 forks source link

Install error and usage guidance #1

Open j-hotlink opened 5 years ago

j-hotlink commented 5 years ago

Hi, apologies for multiple questions, but as this is the first issue I'm taking a liberty...

  1. I'm receiveing the error(s) below when trying to install (into a docker container). I'm new to bucklescript (& npm) - do you have any advice on how to resolve?

  2. I'm uncertain if/how the injection of JSX into Vdom.t nodes affects the purity of tea - can you give some pointers on this?

  3. Do you forsee any significant issues getting your library to work with ocaml syntax (which I use) rather than reason?

Many thanks.

root@hotsite-bs:/volume/host yarn add --dev ppx-tea-jsx
yarn add v1.7.0
warning ../../package.json: No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
[1/3] ⢀ bs-platform
[3/3] ⢀ ppx-tea-jsx
error /volume/host/node_modules/ppx-tea-jsx: Command failed.
Exit code: 2
Command: bsb -make-world -backend native && cp lib/bs/native/ppx_tea_jsx.native ppx
Arguments: 
Directory: /volume/host/node_modules/ppx-tea-jsx
Output:

root@hotsite-bs:/volume/host cd /volume/host/node_modules/ppx-tea-jsx
root@hotsite-bs:/volume/host/node_modules/ppx-tea-jsx bsb -make-world -backend native
/usr/local/share/.config/yarn/global/node_modules/bs-platform/lib/bsb.exe: unknown option '-backend'.
Usage : bsb.exe  -- 
For ninja options, try ninja -h 
ninja will be loaded either by just running `bsb.exe' or `bsb.exe .. -- ..`
It is always recommended to run ninja via bsb.exe 
Bsb options are:
  -v  Print version and exit
  -version  Print version and exit
  -verbose  Set the output(from bsb) to be verbose
  -w  Watch mode
  -clean-world  Clean all bs dependencies
  -clean  Clean only current project
  -make-world  Build all dependencies and itself 
  -init  Init sample project to get started. Note (`bsb -init sample` will create a sample project while `bsb -init .` will reuse current directory)
  -theme  The theme for project initialization, default is basic(https://github.com/bucklescript/bucklescript/tree/master/jscomp/bsb/templates)
  -regen  (internal) Always regenerate build.ninja no matter bsconfig.json is changed or not (for debugging purpose)
  -query  (internal)Query metadata about the build
  -themes  List all available themes
  -where  Show where bsb.exe is located
  -help  Display this list of options
  --help  Display this list of options
root@hotsite-bs:/volume/host/node_modules/ppx-tea-jsx bsb -make-world
File "bsconfig.json", line 5:
Error: type field expect "dev" literal  
For more details, please checkout the schema http://bucklescript.github.io/bucklescript/docson/#build-schema.json
root@hotsite-bs:/volume/host/node_modules/ppx-tea-jsx cat bsconfig.json 
{
  "name": "ppx-tea-jsx",
  "refmt": 3,
  "sources": [
    { "dir": "src", "type": "ppx" },
    { "dir": "test", "type": "dev", "subdirs": true, "ppx": ["Ppx_tea_jsx"] }
  ],
  "ocaml-dependencies": ["compiler-libs"],
  "entries": [
    {
      "backend": "native",
      "type": "ppx",
      "main-module": "Ppx_tea_jsx"
    }
  ],
  "public": ["Ppx_tea_jsx"],
  "warnings": {
    "number": "+R",
    "error": "+5+101+8+R"
  }
}
root@hotsite-bs:/volume/host/node_modules/ppx-tea-jsx 

OvermindDL1 commented 5 years ago

I'm not the author of this but I am of bucklescript-tea.

I'm uncertain if/how the injection of JSX into Vdom.t nodes affects the purity of tea - can you give some pointers on this?

Nope, views are immutable, they should be fine, it's just a mapper from the JSX PPX output to the view calls instead.

Do you forsee any significant issues getting your library to work with ocaml syntax (which I use) rather than reason?

I wouldn't see any issues, but I've not tried yet. From my understanding the JSX PPX works fine in OCaml (since reasonml compiles to ocaml, it would have to, you can use refmt to convert reason to ocaml to see how it works).

I'm receiveing the error(s) below when trying to install (into a docker container). I'm new to bucklescript (& npm) - do you have any advice on how to resolve?

Can you post your package.json file as well? And do you have a sample github project that we can clone and try running?

j-hotlink commented 5 years ago

I'm not the author of this but I am of bucklescript-tea.

Thanks for the reply, and the really cool library! Been using it for less than a week but already much happier than I was with Elm.


I'm uncertain if/how the injection of JSX into Vdom.t nodes affects the purity of tea - can you give some pointers on this?

Nope, views are immutable, they should be fine, it's just a mapper from the JSX PPX output to the view calls instead.

I'm not sure I understand - are you saying JSX views are immutable? I thought JSX functions could respond to browser events and directly change the browser dom outside of the elm update cycle - creating a problem... or is that incorrect?


Do you forsee any significant issues getting your library to work with ocaml syntax (which I use) rather than reason?

I wouldn't see any issues, but I've not tried yet. From my understanding the JSX PPX works fine in OCaml (since reasonml compiles to ocaml, it would have to, you can use refmt to convert reason to ocaml to see how it works).

Thanks, I'll have to look into this further.


I'm receiving the error(s) below when trying to install (into a docker container). I'm new to bucklescript (& npm) - do you have any advice on how to resolve?

Can you post your package.json file as well? And do you have a sample github project that we can clone and try running?

I've copied my package.json below in case it's helpful. I'm unfamiliar with the nodejs ecosystem (spent years avoiding it), so I expect I'll be able to resolve this manually with a bit more Google determination and time. I hope it's caused by my inexperience rather than a packaged error.

{
    "name": "test-project",
    "version": "0.1.0",
    "scripts": {
        "serve": "serve release",
        "clean": "bsb -clean-world",
        "build:bsb": "bsb -make-world",
        "build:js": "rollup -c",
        "build": "run-s build:bsb build:js",
        "watch:bsb": "bsb -make-world -w",
        "watch:js": "rollup -c -w",
        "watch": "run-p watch:bsb watch:js serve"
    },
    "keywords": [
        "BuckleScript"
    ],
    "author": "",
    "license": "MIT",
    "dependencies": {
        "bs-platform": "^4.0.7",
        "bucklescript-tea": "^0.9.1"
    },
    "devDependencies": {
        "bs-platform": "^4.0.7",
        "bucklescript-tea": "^0.9.1",
        "npm-run-all": "^4.1.5",
        "rollup": "^0.67.3",
        "rollup-plugin-node-resolve": "^3.4.0",
        "serve": "^10.1.1"
    }
}

I'm interested in the js interop capabilities of this project, but in the short term I needed a tea based Material Design solution. To keep momentum I ported the elm-bulma package (md using only css) to bucklescript-tea. In case it's useful for others: bucklescript-tea-bulma

OvermindDL1 commented 5 years ago

I'm not sure I understand - are you saying JSX views are immutable? I thought JSX functions could respond to browser events and directly change the browser dom outside of the elm update cycle - creating a problem... or is that incorrect?

JSX is just a syntax, it just calls down to the underlying view functions.

And nope, they don't directly call anything, rather what they do is build up a set of 'mappings', and 'later' that is reified to the DOM itself, which is then what sets up the actual events and so forth. :-)

Thanks, I'll have to look into this further.

ReasonML is just a syntax mutator on top of OCaml, it knows nothing about types, it barely knows it's AST, using it literally uses the refmt program behind it to convert to OCaml as it passes it to the OCaml compiler. Thus all ReasonML code is OCaml code, and 99.9999% of OCaml code can be converted to ReasonML code (a couple of corner cases, might be fixed now though), and refmt can convert both ways too. :-)

I've copied my package.json below in case it's helpful. I'm unfamiliar with the nodejs ecosystem (spent years avoiding it), so I expect I'll be able to resolve this manually with a bit more Google determination and time. I hope it's caused by my inexperience rather than a packaged error.

I came from the C++/OCaml world, the NPM ecosystem is... interesting, it both has everything and is completely horrifying at the same time, lol... >.>

So the versions look good, script looks good, rollup is awesome to use, etc... etc... Hmm, yeah at this point I think I need a test project that shows the issue...

I'm interested in the js interop capabilities of this project, but in the short term I needed a tea based Material Design solution. To keep momentum I ported the elm-bulma package (md using only css) to bucklescript-tea. In case it's useful for others: bucklescript-tea-bulma

Oh that looks cool! I actually use a HIGHLY modified version of the CSS library myself, which is kind of Material'ish of what can be done with pure CSS without javascript (which is a surprising amount). The original Repo (and links to examples) is at https://github.com/mildrenben/surface although I have an internal version that is significantly enhanced that I've been meaning to pull out into it's own project if anyone might find it useful. I've made a set of bucklescript-tea wrappers to make the special HTML concoctions to make the CSS work and 'look' like javascript even though it's not. ^.^

ozanmakes commented 5 years ago

@j-hotlink Apologies for the delay, somehow I missed this completely—really need to figure out why Github doesn't send me emails for my own projects but spams me for everything else.

I'm not shipping any prebuilt binaries, and instead compiling the PPX during installation using bsb-native. From what I gathered from the logs, the build command is calling the bsb command from bs-platform instead of bsb-native. I've just tested it with a new project by doing yarn add --dev bs-platform && yarn add --dev ppx-tea-jsx, and it seems to call the correct bsb binary under node_modules/ppx_tea_jsx/node_modules/.bin/bsb. Removing node_modules and calling yarn works as well.

Do you have a .yarnrc somewhere that could affect this? And can you try it with a more up-to-date version of Yarn?

Another thing that would help is to see if bsb-native is installing correctly in your environment. Does other bsb-native based syntax extensions work for you? yarn add --dev let-anything or yarn add lenses-ppx should help you find out. When the installation is successful, you should end up with a binary under node_modules/<package_name>/ppx.

ozanmakes commented 5 years ago

Thanks for the replies @OvermindDL1!

I'm uncertain if/how the injection of JSX into Vdom.t nodes affects the purity of tea - can you give some pointers on this?

Nope, views are immutable, they should be fine, it's just a mapper from the JSX PPX output to the view calls instead.

I should emphasize that the PPX calls constructors such as Vdom.Node and Vdom.RawProp directly, and doesn't use the functions under Tea.Html or Tea.Html2 (most of the time). In the end, you still end up with the same tree you'd get by calling those functions directly, if you encounter any difference in behavior please file an issue.

Do you forsee any significant issues getting your library to work with ocaml syntax (which I use) rather than reason?

This won't work unfortunately. This PPX works by piggybacking on Reason's JSX support by transforming the [@JSX] annotations generated by refmt. You can see an example of it here.

For this, a similar approach to ppx_bsx can be taken. Actually, if ppx_bsx is adding those annotations at the same locations, running ppx-tea-jsx after it might work, I haven't confirmed it though. I actually prefer working with plain lists and function calls in OCaml syntax.

OvermindDL1 commented 5 years ago

I should emphasize that the PPX calls constructors such as Vdom.Node and Vdom.RawProp directly,

Perfectly fine, the functions in those HTML2? modules just do the same. :-)

This won't work unfortunately. This PPX works by piggybacking on Reason's JSX support by transforming the [@JSX] annotations generated by refmt. You can see an example of it here.

How does that work with refmt converting back to ocaml though, All PPX's work on OCaml AST.

I actually prefer working with plain lists and function calls in OCaml syntax.

Likewise yeah, it's clean enough as it is unlike ReasonML.

ozanmakes commented 5 years ago

How does that work with refmt converting back to ocaml though, All PPX's work on OCaml AST.

Yes, but this one looks for [@JSX] attributes left by refmt. It's documented here: https://reasonml.github.io/docs/en/jsx#tip-tricks

OvermindDL1 commented 5 years ago

Yes, but this one looks for [@JSX] attributes left by refmt. It's documented here: reasonml.github.io/docs/en/jsx#tip-tricks

So that's pretty expected then. I'm curious how the refmt ReasonML/JSX -> OCaml actually looks as an example though. :-)

ozanmakes commented 5 years ago

This won't work unfortunately. This PPX works by piggybacking on Reason's JSX support by transforming the [@JSX] annotations generated by refmt. You can see an example of it here.

Here is a much better example than the link above:

https://reasonml.github.io/en/try?rrjsx=true&reason=LYewJgrgNgpgBAVQM4wE5wLxwN4Cg5ywAucAxiMAA4gB2MNJWASjAIZK0uulEB0SRVkRiwkSAMIVqdBgAoARMjTyAlAG5c+QjBLBWAa3hZZAPxqtgMADRkAFgEsoYVPRWYAfDi0Fev8lVp6IitvOBcaMDQALjgAfRQoADMPUIIAHjB7ADd3VIIcLg4aLh5+IlR7GgBzWXNLFQBfPPSAI3QAelz87oK2IpK+VlRUVgBPWVIHJ3DGvLT2zJyQggaNVc1QSFg4AAV7HggXTC8CYjIpQIZjws42UoEhERgxSQCZIgU9g5dVDS0zvSGY6mJCoUgYAD8Nlik0czlcHhO+V8vH80iCy3y4UiqBi8REyQwnjS9mAVTgENBpDgnUx63WuDOVOOADlAn8zrFMFo0l18hlsmQoOwkCyLDAMPIWlAIDB5MTKpQICQsqwZRL5LYRFAQPIacSFtk+eklOg6hqAPIAL1YNHlcDSXyIh3glLB+od7VNfPm7g0QA

OCaml output is on bottom left.

<> </> (Fragment) helps prevent unnecessary wrapping in divs when we just want to return an array of elements.

Lowercase tags end up like React.createElement("div") in JS output, while uppercase ones call ModuleName.make.

OvermindDL1 commented 5 years ago

Ah very cool, thanks for that! :-)

Phylodome commented 5 years ago

@j-hotlink Did you ever get to the bottom of this? I'm experiencing the same issue w/ a different reason package that expects bsb in the postinstall script to be that of bsb-native, when it's in fact that of bs-platform.

I'm also only running into issues when containerizing via the default node container, running atop linux. The local build process on darwin executes normally.

j-hotlink commented 5 years ago

Sorry, I've nothing helpful to add. Although I like the project, other pressures required I KISS with ocaml

Phylodome commented 5 years ago

Got it. Thanks for letting me know.