Skip to content

@accounts/types : add a types package which contains common types #173

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

Merged
merged 8 commits into from
Mar 15, 2018

Conversation

Aetherall
Copy link
Member

No description provided.

@codecov-io
Copy link

codecov-io commented Mar 12, 2018

Codecov Report

Merging #173 into master will increase coverage by 0.08%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #173      +/-   ##
==========================================
+ Coverage   92.16%   92.24%   +0.08%     
==========================================
  Files          42       43       +1     
  Lines        1034     1045      +11     
  Branches      124      124              
==========================================
+ Hits          953      964      +11     
  Misses         70       70              
  Partials       11       11
Impacted Files Coverage Δ
packages/types/src/index.ts 100% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e120cf5...edeab6a. Read the comment docs.

@Aetherall Aetherall changed the title @accounts/types add a types package which contains common types @accounts/types : add a types package which contains common types Mar 12, 2018
@pradel
Copy link
Member

pradel commented Mar 13, 2018

Why do we need a new types package, can this go to common instead?

@Aetherall
Copy link
Member Author

Aetherall commented Mar 13, 2018

In fact the common package actually is a dependency in some packages and a devDependency in others
the common package exports utilities that will no longer need to be shared across the suite in the future versions of Accounts-Js
(actually most of them are already moved to the corresponding package)

That's why I am creating @accounts/types and @accounts/error

@accounts/error will be the dependency
@accounts/types will be the devDependency

It keeps the relation between packages simple

Copy link
Member

@davidyaha davidyaha left a comment

Choose a reason for hiding this comment

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

These are only common types right?
Maybe add a readme that explains that

},
"repository": {
"type": "git",
"url": "https://github.com/js-accounts/accounts/tree/master/packages/server"
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh yes I am changing that

@Aetherall
Copy link
Member Author

There is also DatabaseInterface because it makes more sense to have it here
I am adding the readme

@davidyaha
Copy link
Member

@Aetherall A user with TS in his project needs to add this package to devDependencies as well?

@Aetherall
Copy link
Member Author

@davidyaha only if he is using those types I suppose...


It contains the types used across the Accouts Suite.

#### Usage : This package is used internally by the suite. It's not needed to install it
Copy link
Member

Choose a reason for hiding this comment

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

OK, so maybe remove that.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

export { ImpersonationResult as ImpersonateReturnType } from './types/impersonation-result'


// ? Operation Parameters
Copy link
Member

@pradel pradel Mar 13, 2018

Choose a reason for hiding this comment

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

maybe we will need to figure this before merging no?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes actually I want to discuss it ASAP

Copy link
Member

Choose a reason for hiding this comment

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

So this will be used on the password server and password client right?

Copy link
Member Author

@Aetherall Aetherall Mar 13, 2018

Choose a reason for hiding this comment

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

the @accounts/types package will be used on pretty much every @accounts package, as a devDependency

Copy link
Member

Choose a reason for hiding this comment

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

I mean the type

Copy link
Member Author

@Aetherall Aetherall Mar 13, 2018

Choose a reason for hiding this comment

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

Yes it is used already

Copy link
Member

Choose a reason for hiding this comment

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

What is the idea of Operation Parameters?

Copy link
Member Author

@Aetherall Aetherall Mar 14, 2018

Choose a reason for hiding this comment

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

For several operations, the function expect one object as parameters which contains all the informations the operation needs to execute

Actually this is not consistent because some operation are using this pattern and others are not

I would prefer to not use this way in order to simplify the workflow, but for this package to be compatible with the actual state suite, those types are needed


export interface User {
username?: string;
email?: string;
Copy link
Member

Choose a reason for hiding this comment

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

is this line accurate?

Copy link
Member Author

@Aetherall Aetherall Mar 13, 2018

Choose a reason for hiding this comment

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

In fact I just copied the types and renamed it
But if you look at the index.ts it's all renamed as original for compatibility
It's a part of the type renaming we will discuss in a meeting ( the sooner the better )

Copy link
Member

Choose a reason for hiding this comment

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

Yeah I now but was wondering if this is used or not ^^

Copy link
Member

Choose a reason for hiding this comment

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

I think it should not be used no?

Copy link
Member Author

@Aetherall Aetherall Mar 13, 2018

Choose a reason for hiding this comment

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

you mean the email:string field?
or the whole User Interface ?

Copy link
Member

Choose a reason for hiding this comment

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

email string field

Copy link
Member Author

@Aetherall Aetherall Mar 13, 2018

Choose a reason for hiding this comment

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

I agree, this was on the UserObjectType interface
I do not use it in the next branch neither
I was assuming the client used it
I am removing this right now

@Aetherall Aetherall mentioned this pull request Mar 13, 2018
12 tasks
@davidyaha davidyaha merged commit 34ec9db into master Mar 15, 2018
@davidyaha davidyaha deleted the package/types branch March 15, 2018 17:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants