@rigor789 The paths are fixed on master apparently but the project is not released afterwards. Npm is resolving to old code hence this is still broken on builds. We need a new release to fix this issue please.

@yerol I can create a new release, but do know that this is very much a WIP, and there is nothing in place for actually building the project, this only scaffolds the files and folders, nothing else.

@rigor789 Yeah I figured. I actually fixed couple of other issues after resolving this one locally. I'll create a PR for you with those changes and then you can release maybe. Should be ready in a couple of hours.

On a separate note, I'll take a stab at combining the tns build process from cli-template project if you don't mind. Would be great if you can share your plans (structural mostly) for this plugin going forward. Thanks.

@yerol that would be awesome!

The initial plan is to allow building an app with cli 3.x from the same exact file structure as a regular web based project.

In order to get this working we need to

• overwrite web specific files with NativeScript specific ones (this is somewhat done, just needs to be updated)
• add additional commands to the package json (watch:ios, watch:android, build:ios, build:android etc.)
• make these commands do what they are supposed to:
  • initialize a NativeScript project
  • proxy commands to the tns cli (tns run android tns run ios etc)
• Nice to have: UI for the new Vue CLI UI, so the most common tasks can be done visually
  • include configuration for all required keys for releasing
  • buttons to start the app, trigger a rebuild, open a debugger window (chrome devtools, and hopefully VueDevtools at some point - this is not yet possible).

@rigor789 PR is ready for review. I have bumped up the version number to 0.0.3 as this package is currently on 0.0.2 on npm even though package.json says it is 0.0.1.

I'll continue with tns build after this. I'll start with copying over the logic from cli-template. Might need your input, will let you know.

@rigor789 btw, will need you to npm publish after this so this issue can be resolved.

@c6p The PR is now merged and this issue should be resolved now. Although still need an npm publish from @rigor789

I'm very close to integrating tns build as well. Will send another PR soon.

@yerol @jiraiya972 figured out a neat way to avoid the template folder in the app structure, we will be moving towards a similar solution for this plugin as well as the vue-cli-template. https://github.com/jiraiya972/nativescript-vue-cli-template

We can most likely combine the two efforts soon!

looks very interesting. Could be a bit tricky to get it working as is with vue cli 3 though. we'll see. Thanks for letting me know.

I think we can get it working with vue cli3, I haven't got the time to properly test it, but we can create a webpack.config.js in the root of the project (using a cli3 generator) and export the resolved config from @vue/cli-service/webpack.config.js, which is the final config after all the plugins are applied. That way tns run <android|ios> --bundle commands will work in the vue cli3 project (the src folder needs to be renamed to app as well, but I think that should be doable easily).

Hello I started to look at how vue-cli3 works. The integration of my template seems a bit "complex" than that of the old because vue-cli completely masks the file webpack.config.js. This makes it impossible to use the --bundle option of the tns command.

I have to make sure that the target remains the dist directory and launch the tns command from this directory which is the behavior of the current template.

There is also the directory name in which is configurable via the nsconfig.json file. It is read and passed as an argument to webpack via the tns command. here I will have to put it in the webpack.

The only improvement of my template would be the deletion of the template directory that must be modified to use the tns plugins.

I think we should not export the global webpack.config.js to keep phylosophy from vue-cli3. The same file for everyone to symplify updates to existing projects.

I still have trouble understanding how vue-cli handles incompatible plugins. For example babel and typescript.
The nativescript plugin will be incompatible with a lot of other I guess. For example, that of the E2E test.
We would have a complicated cli where we do not know what to choose as an option for fear of having a project that does not work in the end.

@jiraiya972 I figured that we can have a webpack config in the root of a cli 3.x project, and export the generated config from @vue/cli-service/weback.config.js. This way the --bundle flag should pick it up without issues as long as we make sure the config is generated the same way...

hi, folks, I'd love to reboot this project to see if we can permanently move away from the old 'CLI 2' means of invoking vue init to create a project, and move instead towards the CLI 3 method. I think this project needs to be updated to reflect NativeScript-Vue 2.0.x and the newer template structure, what would you prefer I look at? I'd like to help (also to learn more about building plugins). thanks!

@rigor789, @jlooper

I should hopefully have a pull request for getting the entire pipeline setup for CLI 3 in the next few days. I have it manually working right now and am trying to back my way into getting the entire automation and template process working.

right now I can run npm run build:android and it will call a npm script that runs "vue-cli-service tns --android --mode android and it will build the entire thing. In my manual testing it will also essentially do a tns run android as well.

This will require the use of a temporary webpack.config.js be written to the root of the directory. With webpack-chain and the CLI we can grab the dynamic config from the CLI and write it out, run the tns commands and then delete the file at the end. This is really a hard limitation of the nativescript-dev-webpack project where they hard code the location to expect the webpack.config.js file to live. It's not even configurable to point it to another directory. It flat out requires a file and we can't pass in the config at runtime and let it work. Would probably require a major rewrite of that project to enable that to happen.

anyways, hopefully by no later than early next week I can submit a PR and we can finally use CLI 3 for this stuff.

This is really exciting to hear! Is the structure of the app built aligned to the new folder structure?

I think so. I generated a CLI 3 project, then invoked this plugin from a project in another working directory so that I can edit the plugin properties in real time and work through the issues. Lots of unnecessary stuff in that directory right now for Unit Testing, config's etc, but the src directory is CLI 3. The only thing that I haven't overcome yet is the outputDir is hardcoded to platforms. I haven't explored fully yet if that's another nativescript-dev-webpack project issue or not.

Another major caveat that isn't specific to this plugin is that vue-router isn't usable with Nativescript. I've chosen to leave that in the config for now as I have a proof of concept on CLI 2 that allows you to develop dual purpose Nativescript/Web SFC's.

What I foresee doing after this initial version of getting the CLI 3 plugin working is to then give another command line option that will pass a mode that will build for the web as well.

I've essentially took the webpack structure from the CLI 2 nativescript template project and converted it to webpack-chain to push the config into something CLI 3 finds acceptable.

Hi guys,

Sorry I couldn't respond in time to save you the trouble but we started working on this with @rigor789 couple of weeks ago. Our aim is to have a nativescript-vue app living side by side with a vue cli 3.x app and enable code sharing between the two. @jawa-the-hutt not sure if you have heard about it yet but our goal is to integrate NativeScript-Vue-Web project into this plugin so we can code once using Nativescript-Vue components/syntax and get them working in Android, IOS and Web. All equivalent web components are currently available in NativeScript-Vue-Web.

As for the requirements for this plugin, we have created a small list, which is available in the following gist:

https://gist.github.com/rigor789/637877bad549ada1aa1662198535e362

Please have a look and let me know if these are in line with what you are doing. I'm sure @rigor789 will update you on the current progress for the plugin but it would be great to combine the efforts rather than duplicating the work.

@yerol

Those requirements sound pretty similar to what I've been doing. It appears the main difference is for the mutli use components, I was combining everything into one .vue file instead of having specific .vue files for each platform.

In my webpack config I was doing something like this with the vue-loader. It was really just a glorified string.replace method of yanking out the unwanted blocks.

{
    test: /\.vue$/,
    use: [
        {
            loader: "vue-loader",
            options: {
                compiler: NsVueTemplateCompiler,
            }
        },
        {
            loader: 'string-replace-loader',
            options: {
                search: '<template web>[\\s\\S]*?<\/template>',
                replace: '',
                flags: 'gim',
                strict: true
            }
        },
    ],
},

I would be interested in helping out however I can. Let me know and I'll dig in where possible.

I've gone ahead and finished working on the change I was making and have committed them into my fork

It does the following:

1. Allows you to develop for both native and web in on SFC. You use <template native> and <template web> blocks and during build, it will detect which platform you are building for and it will remove the template from the platform you aren't. Downside is in the <script> tags, you will sometimes have to do some platform detection when you need the ability to do something different between platforms.
2. the npm run commands are as follows:
   npm run serve:android
npm run serve:ios
npm run serve:web
   -- Build version of those where you replace serve with build
3. It doesn't use nativescript-vue-loader as the way I'm doing it, it's not needed. I realize that was one of the goals in the gist, but my thought is if it's not needed, then it's one less dependency and/or project for someone to maintain.
4. It retains the base CLI 3 file and folder structure
5. It does not use vue-router when building/serving for native devices
6. To run the actual tns commands, it uses child-process to run the command and pipes the output to the console so you can see all pertinent info.
7. Heavy use of webpack-chain to create the web or native webpack config on the fly.
8. During build/serve it copies the dynamic webpack.config.js from the vue-cli-service to the base of the project directory and then when done, it will delete it. thus, there is no permanent webpack.config.js file that has to be maintained in either the cli plugin project, or the developer's project.

Still lots of room for improvements and just making the code better, but for now, I have something that allows me to develop against both in one SFC. One of the next things is I would like to this detect when a CLI 3 project is being done with Typescript and make the appropriate adjustments to file.

Very excited! I'm curious...what if I have a project built for the web...can I use this plugin to bolt on a mobile app?

@jlooper - That's a very good question. I'm going to add a prompt that will give you the option of not overwriting or editing existing files when you invoke the plugin. The largest risk is to App.vue. Of course best practice would be to commit the project before invoking the plugin in case it makes unintended changes, but it would be best to try and prevent as many of those as possible up front.

@jlooper I've merged a PR in my fork that adds a prompt: Is this a new project? It will default to No assuming the project is existing and as such, it will try and be as non-destructive as possible to existing files and setup. We could default to yes, but if someone just spams the enter key it might overwrite an existing app.vue component in a way that keeps their project from working.

With leaving it at the default prompt, it will rename main.js to main.web.js and won't touch any of the other structure in src other than copying in the App_Resources folder. It will still copy in .env files and attempt to edit babel.config.js if it exists.

I do want to be clear, this is something i've worked on my own without @yerol or @rigor789 being involved or gotten their blessing for. They may end up going a completely separate direction with this plugin. Use at your own risk and make sure you have a current commit in place before invoking my fork.

@jawa-the-hutt this looks like great progress. I'll review it and get back to you today. @rigor789 is not around these days. Can you please find me on nativescript community slack so we can take the discussion there?

Igor is here, he's just a bit swamped. I'm excited to see what all these folks say. I really like this non-destructive new prompt! :) Let's keep moving!

Just a quick update. Yigit and I synced up outside of this issue and he's been working with me to scope out and execute on getting this plugin fully working.

No timetable for when a PR will be submitted and approved, but we are on the right track.

Any news?

@eladcandroid

PR #5 should fix the issue you are seeing. You can head here: https://github.com/jawa-the-hutt/vue-cli-plugin-nativescript-vue and follow the README to try it out.

Be aware however, that we are still actively making changes inside some other branches in that repository that will eventually make its way here so while the current master branch works, it's not the final version of what will end up here within PR #5.

@jawa-the-hutt It Looks awesome! I'll check it! thanks a lot

@jawa-the-hutt I can't open issues because it's a fork - so i'm writing here..
Can you please support dart-sass?

PR #5 closes this.

Any news?

This error continues... :(