Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TS branch intial release #20

Closed
wants to merge 1 commit into from
Closed

TS branch intial release #20

wants to merge 1 commit into from

Conversation

JohnMica
Copy link

i am creating this PR agains the TS branch (that is what i understood from your latest replies Richard).

@@ -0,0 +1,30 @@
{
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just making a note: this file replaces babel.config.js

rules: {
"space-before-function-paren": ["error", "never"],
// 'space-before-function-paren': ['error', 'never'],
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can probably be deleted altogether. the spacing conventions are probably set in one of the recommended linters above.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the idea would be that having at least 1 rule would make thing easier for users that would have different preferences when it comes to editor / linting rules

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok. I think we might also want the comma-dangle rule in here:

"comma-dangle": ["error", "never"],

return {
require: ["./test/helpers/ava.setup.js"],
ignoredByWatcher: ["!**/*.{js,vue}"],
babel: true,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a personal preference, I find it useful to keep the files prop in there, even though it adds verbosity. I find it makes it much easier to test specific features in watch mode (but others have their preferences too). I've tried it both ways (the way you have here, and with files list; I can work faster with "test.only" and only specific files enabled)

}
},
computed: {
chartOptions() {
return {
chart: {
map: 'africa'
map: 'africa',
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine for now, but I think eventually it'd make for much cleaner code if the chartOptions were stored somewhere else (in their own json), and then imported as needed, tweaking only the props of interest, such as the title text. But for now, this is fine.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that could work indeed and make things a bit simpler

@@ -0,0 +1,7 @@
# LAYOUTS
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's delete this one for now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

even with this file not present, i still think it will be solved as a default layout by nuxt, no ?

i will remove this anyways

head: {
title: process.env.npm_package_name || '',
title: "highcharts",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be reverted back to process.env.npm_package_name. This one of those minor things that's easy to miss as we go from project to project. This will be one less chore for us in the future.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

// Modules for dev and build (recommended) (https://go.nuxtjs.dev/config-modules)
buildModules: [
// https://go.nuxtjs.dev/typescript
"@nuxt/typescript-build"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have insight as to why the "require.context" error goes away in SSR-mode when using the typescript-build? I think it would be helpful to know not just here, but I think some folks ask about it on stackoverflow and other projects. (i.e., it's not a highcharts-specific issue, and others could probably be helped by the answer)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am not 100% sure but

  • could be that using nuxt TS actually figures out the type of require in this particular function ?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. for some reason, I still encounter the warning, even with the ts build. I'll take some time to investigate the issue. I know the block of code causing it, I just need to troubleshoot ways to mute the warning (webpack/webpack#2675 might give some insight)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I was able to mute the warning and get this fixed. The key was to mock out the require.context.keys() method not require.context, which is what we want from our tests anyway.

"test": "cross-env NODE_ENV=test npm run test:specs:cov && npm run test:e2e:cov",
"test:specs": "cross-env TEST=specs ava --config specs.config.js",
"test:unit": "cross-env TEST=unit ava ./test/specs/**/*",
Copy link
Owner

@richardeschloss richardeschloss Dec 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this brief version is indeed prettier, it may come back to bite us later on when we want unit vs. e2e tests. I think it's easier to maintain when the script is instructed to use the specific ava config (the config for unit tests) and in that, it's files prop can specify the glob. That way, even if globs get checked in, but a specific feature is being worked on, it's easy to see in PRs if someone changed the glob. (personal preference, more my opinion)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so revert to the initial testing scripts?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so. That way any testing config changes take place in the respective ava config files. I find it's easier to manage the diffs that way. The test:unit and TEST=unit though can stay as-is because that's more common convention.

"test:e2e:cov": "cross-env TEST=e2e nyc --no-clean ava --timeout=10m --config e2e.config.js",
"test:e2e:watch": "cross-env TEST=e2e ava --config e2e.config.js --color --watch"
},
"dependencies": {
"highcharts": "^8.1.0"
"@nuxt/typescript-runtime": "^2.0.0",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this alone fix the "require.context" issue when someone installs the library? Or will they also need @nuxt/typescript-build?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

even now using the Nuxt TS would actually add @nuxt/typescript-build to the deps and in the 'how to' it is mentioned as well.
so if users want the TS they do need the package (until v3 is released and we will need to figure out what and how)

@@ -21,7 +21,7 @@ export default {
StockChart,
MapChart,
QuickMods,
SunburstChart
}
SunburstChart,
Copy link
Owner

@richardeschloss richardeschloss Dec 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. do the recommended lint conventions have dangling commas?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it could be that my Vetur options might have this by default ?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I put the eslint recommendation above (for the eslint file)

@@ -0,0 +1,29 @@
import { resolve } from 'path'
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this may be extraneous for now. It may be a useful blueprint for e2e testing, but I think it can be deleted (or safely stashed away with git stash)

@@ -0,0 +1,15 @@
if (process.env.TEST === 'unit') {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to keep ava.setup.js as-is for now. It also requires browser-env which I think was needed for some tests. Having this file in helpers may be a good place for it though.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i will revert the file to its original setup

@@ -0,0 +1,8 @@
import test from 'ava'
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extraneous. Can be removed.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

@richardeschloss
Copy link
Owner

richardeschloss commented Dec 19, 2020

Also, can you please run npm run test:specs:cov to ensure all tests pass still with 100% coverage? I am pretty confident they will

@JohnMica
Copy link
Author

Also, can you please run npm run test:specs:cov to ensure all tests pass still with 100% coverage? I am pretty confident they will

this seems to be causing an error

[Error - 10:15:37 AM] Error: .eslintrc.js » @nuxtjs/eslint-config-typescript » @nuxtjs/eslint-config:
	Environment key "jest/globals" is unknown```
looking into this now

@richardeschloss
Copy link
Owner

For that error, I think you might need eslint-plugin-jest ?

@richardeschloss
Copy link
Owner

Branch feat/ts now contains the nuxt-ts deps. Closing this PR. Thank you for your help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants