-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
Conversation
@@ -0,0 +1,30 @@ | |||
{ |
There was a problem hiding this comment.
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'], |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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', |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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/**/*", |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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' |
There was a problem hiding this comment.
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') { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extraneous. Can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do
Also, can you please run |
this seems to be causing an error
|
For that error, I think you might need eslint-plugin-jest ? |
Branch feat/ts now contains the nuxt-ts deps. Closing this PR. Thank you for your help. |
i am creating this PR agains the TS branch (that is what i understood from your latest replies Richard).